Re: Getting started with CSharpAddIn

[Govert van Drimmelen]

Hi Jeff,

Flattery will get you anywhere :-)

I see from other other post that you've figured this out.

I think the step-by-step C# guide here:
http://www.codeplex.com/Download?ProjectName=exceldna&DownloadId=372242
might help to take you through the steps of making a new C# project
and setting everything up the right way.

If you come from a VBA background you might prefer to use VB.NET - it
gives you a familiar syntax with the same performance and
functionality as C#. If you are interested in this direction you might
look at the posts by Patrick O'Beirne about converting VBA projects to
VB.NET with Excel-DNA. His most recent blog post and updated documents
can be found here:
http://sysmod.wordpress.com/2012/11/06/migrating-an-excel-vba-add-in-to-a-vb-net-xll-with-excel-dna-update/.

Regards,
Govert


On Nov 23, 7:50 pm, Jeff Rose <jro...@gmail.com> wrote:
> First post on the group for me. Nice to meet you!
>
> May I first just say that getting started with ExcelDNA has been totally
> amazing. The clarity of the documentation, both in the description of
> ExcelDNA on the website, and in the files included with ExcelDNA is top
> notch. I really couldn't hope for better. A big thanks for making
> everything so straightforward and explaining the goals and limitations of
> the project so well!
>
> But on to my issue:
>
> I ran through the ExcelDNA "GettingStarted.txt" last night and everything
> went without any problems, so I'm at a point where I can call to external
> C# libraries from Excel. Now I'd like to be able to set up Visual Studio
> 2010 as my development environment so that I can take advantage of
> breakpoints and the awesome VS debugging features (and the testing
> features, too).
>
> I noticed the CSharpAddIn solution included in the Samples folder of the
> distribution and began following the steps to get it set up, but I ran into
> some trouble very early on. Particularly with this paragraph:
>
> Debugging
>
> > ---------------
> > Easiest debugging is to put the full path of Excel.exe into  Project
> > Properties -> Debugging tab, Start external program:.
> > In the command line arguments: box, enter the full path to SampleCS.xll,
> > or just File->Open the SampleCS.xll when Excel is running. Then start
> > debugging with F5.
>
> Where can this SampleCS.xll be found? As far as I'm aware, the only .xll
> files packaged with the distro are ExcelDna.xll and ExcelDna64.xll. If
> "SampleCS" just supposed to be substituted for the .xll file I intend to be
> loaded? When I try this, it doesn't appear to work, and returns the
> following build error upon starting debug mode (F5):
>
> Error 1 The command "echo F | xcopy C:\Users\Jeff\Google
>
> > Drive\Workspace\C#\Libraries\ExcelDNA\Distribution\Samples\VisualStudio\CSh arpAddIn\..\..\..\ExcelDna.xll
> > C:\Users\Jeff\Google
> > Drive\Workspace\C#\Libraries\ExcelDNA\Distribution\Samples\VisualStudio\CSh arpAddIn\bin\Debug\SampleCS.xll
> > /C /Y" exited with code 4. CSharpAddIn
>
> What am I missing about this process? If I could get over this hurdle it
> would be totally fantastic, because I'm a sick and tired of using VBA and
> sick and tired of the Excel VBA editor!
>
> Thanks for making such a stand-up library. If this is my one major hiccup
> in getting up and working with .NET in Excel, then I give this two thumbs
> up.
>
> Jeff

[Naju Mancheril]

Hi Jeff,

Have you read https://groups.google.com/d/topic/exceldna/stk7Ll6Ya70/discussion?

It's basically about my attempts to get breakpoints working, for my code, ExcelDna C# code, and ExcelDna C++ code.

Currently, I do the following:

(1) Compile my code and get the managed .dlls, .xll, and .dna (config) file into my bin\Debug\
(2) Start Excel manually
(3) Set up the addin using the addin manager (Alt+T, I) will bring this up
(4) Close Excel (so Excel can write it's new addin list to the registry)

At this point, any time Excel starts, it will load my addin.

For breakpoints in my functions

(1) Start Excel
(2) Attach to Excel with VIsual Studio (Debug -> Attach to Process)
(3) Force function to run in Excel ... my breakpoint is hit.

For breakpoints in my startup code

(1) Set an environment variable (waitfordna) to 1
(2) Make my EARLIEST addin startup code check for this environment variable. If it's set, show a windows message box.
(3) When Excel starts, it will show this box. I attach Visual Studio before I hit OK in the box.
(4) At this point, Excel hits my breakpoint

When I first started developing .NET Excel addins with ManagedXLL, I used the "Start external program" feature of VS to start Excel, but that only works something like 80% of the time. The message box approach has worked well something like 95% of the time.

If this helps, please let us know. If not, can you post more details on where exactly your breakpoints are?

[Govert van Drimmelen]

Hi Jeff,

If you're trying out the Visual Studio sample in the Distribution
\Samples\VisualStudio\CSharpAddin, then you'll see the project has a
post-build step that copies ExcelDna.xll to the output directory as
SampleCS.xll. The post-build command-line looks like this:
echo F | xcopy $(ProjectDir)..\..\..\ExcelDna.xll $
(TargetDir)SampleCS.xll /C /Y

This creates the SamplesCS.xll file you're looking for. If your build
is not creating this file, it might be because you have moved the
relative directories, so that the post-build step is no longer finding
ExcelDna.xll where expected.

In the C# Step-by-step guide on the CodePlex site you'll see me
describing a different approach, where I add a renamed copy of the
ExcelDna.xll file as a 'content' file into the project, set it to Copy
to Output, and then this relative path issue is no longer a concern.

---

The issues and discussion that Naju describes relate to debugging the
Excel-DNA code itself, in particular the native Excel-DNA loader. This
can be tricky.
If you are just debugging your add-in library, and targeting .NET 4,
you shouldn't have issues getting the debugging started.

---

A related question that will pop up soon has to do with rebuilding and
reloading the add-in without restarted Excel. For this you need to
attach and detach the debugger to a running process, and use the
<ExternalLibrary Path="..." LoadFromBytes="true" />
option in the .dna file, which prevents Excel for locking your add-in
library. But this is an topic for later....

Regards,
Govert



On Nov 23, 11:55 pm, Naju Mancheril <naju.manche...@gmail.com> wrote:
> Hi Jeff,
>
> Have you readhttps://groups.google.com/d/topic/exceldna/stk7Ll6Ya70/discussion?

[ngm]

OK, two more questions.

(1) Are all your files in your bin\Debug? [.xll, .dna, .dlls]. There are ways to make this work without this constraint, but I'm just wondering how complicated your setup is.

(2) The last time I ran into this empty breakpoints problem, it was because my addin was loading some older assemblies I'd copied into another folder (and not the latest ones in my bin\Debug). This will definitely cause VS to freak out and refuse to load your assemblies. The easiest way to test this is change your function and see if the new implementation runs. For example, make JoinThem return "I AM JOINTHEM" or something. If it still returns the concatenated form, then this is because Excel is referencing different code (maybe the sample implementation?) rather than yours.

[If this is the case, I recommend

(1) Close Excel
(2) Move the Samples folder out of the way
(3) Start Excel ... it should complain that it can't find the addin. That's fine.
(4) Open addin manager (Alt+T, I)
(5) Check or uncheck the dna addin. Excel will complain again that it can't find it and ask you if you want to remove it from the list. Say Yes.
(6) Close Excel
(7) Make sure the addin and .dna files are in your bin\Debug\
(8) Start Excel
(9) Open addin manager (as above)
(10) Browse to your bin\Debug and select the .xll file.

See if this brings in your JoinThem function.

If so, it would be good to restart Excel at this point so it can save it's latest settings. After that, attach VS and test your breakpoint.

[Govert van Drimmelen]

Hi Jeff,

Maybe Visual Studio is attaching the wrong version of the debugger.
Could you try this:

1. Check that you have a RuntimeVersion="v4.0" attribute in the
DnaLibrary tag of your .dna file.
2. Start Excel on its own.
3. Load your add-in from the bin\Debug location.
4. In the Visual Studio, pick Debug->Attach to Process
5. Find and click on Excel.exe in the list
6. Check the "Attach to:" option in the Attach to Process dialog. This
should read only "Managed (v4.0) code". If it doesn't, click
"Select..." and pick the right option.
7. Click "Attach" and see that the title bar of Visual Studio changes
to "... (Running)".
8. Call your function in Excel, expecting your breakpoint to be hit.

You should also clear the option called "Register for COM Interop" in
your add-in project. It can cause other confusions later. Add-in
libraries working with Excel-DNA should never have this option on.

-Govert

On Nov 24, 12:47 am, Jeff Rose <jro...@gmail.com> wrote:
> All right, I'm starting to get a better sense of things now (although
> debugging is still just not working).
>
> Where I'm at right now:
>
> I have created a C# .NET Library project from scratch, rather than using
> CSharpAddIn. My project includes edited ExcelDna.dna and ExcelDna.xll files
> within the project, which are set to be copied into the target folder. The
> ExcelDna.Integration.dll file is in my solution folder, and the reference
> to it is set to not copy it into the target folder, since I've read
> elsewhere that it is redundant if the .xll is there.
>
> I am able to open Excel and load up my .xll file such that I can call C#
> functions from cell formulae. However, if I Attach VS to the Excel.exe
> process, my breakpoints give me warnings saying they cannot be hit.
>
> I thought it best to clarify my current circumstances, since this thread
> isn't so much about the CSharpAddIn solution anymore.
>
> Jeff