June 4th, 2010, 09:36 AM
C# DLL in VS2010 and MS Access
Not sure if this is the right section to post but...
I have a C# .net 3 DLL and a MS Access database that links to the DLL this is all working ok (well mostly)
when I was using VS2008 to debug the code in the DLL all i did was tell VS2008 to start MS access as the external program when i compeld the project add a break point in VS and when i hit that poin VS would pop up and i could debug the code.
Now in VS2010 i have the same setup but if MS access is set as the external program then VS doesnt break on the break points
(I i run using a WinForm test App it will break as i expect)
anyone know what im missing.
Edit: Sorry should add im also using a x64 Bit PC Now
June 7th, 2010, 10:34 AM
Re: C# DLL in VS2010 and MS Access
"Debugging add-ins targeting CLR 2.0 in Visual Studio 2010
I had some problems debugging add-ins if those were loading in CLR 2.0. I would press F5, Excel would start up and my add-in would run but the breakpoints were not getting hit. So I wanted to share what's going on and how to set up your environment in such a way that F5 experience is not completely broken.
There is no magic in the way I usually go about debugging the shared add-in - either shimmed or unshimmed. I set a breakpoint in the OnConnection method in Connect.cs file, open project's properties, go to the Debug section, select the "Start External Program" option and set the full path to my Office application (e.g. "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE"). Next I right click on the project node in the Solution Explorer and select "Set As Startup Project". When I press F5 my breakpoint is hit.
In Visual Studio 2010 the breakpoint is not hit if my add-in is loaded in CLR 2.0. What's going on is that debugger cannot attach to both CLR 4.0 and CLR 2.0 - it actually needs to know before the fact whether it should be using CLR 2.0 debugging engine or CLR 4.0 debugging engine. When you press F5 debugger tries to guess which CLR will be started in the process. The heuristic is based on reading the EXE's .config file where required runtime version is u8sually specified and if the .config file is not found than the debugger fires up the CLR 4.0 debugging engine. As we all know Office application are not bound to any particular version of the CLR so the heuristic miserably fails.
There are actually two ways of dealing with it – one is to put an <YourApp>.exe.config file alongside the.exe itself e.g. when debugging Excel 2007 I will create Excel.exe.config and leave it in the "C:\Program Files\Microsoft Office\Office12" folder.
But my preferred way of dealing with this is different. In the Solution Explorer I will right click on my solution node and select "Add" -> "Existing Project" and open "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE". Next, I will right click on this newly added project and select "Set As Startup Project". Next, I will open the properties for this project and will set the "Debugger Type" property to "Managed (v2.0, v1.1, v1.0)". Now, I will F5 and the breakpoint I've set in OnConnection method will be hit."
With thanks to Misha Shneerson http://blogs.msdn.com/b/mshneer/arch...r-vs-2010.aspx
Found out how to do this seems to be down to the Debugger automaticly picking the wrong debug type.
Click Here to Expand Forum to Full Width
This is a CodeGuru survey question.