nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

.NET 4 DLL in 3.5 Add-in (Or .NET 4 Add-in not Debugging)

RyanCoodey

So I am trying to port over our custom 9.3 toolbars and commands to 10. I am really liking the whole add-ins setup for 10 but am having an issue...

We have some external DLLs we need to reference that are compiled with .NET 4.0, and trying to use these in the new .NET 3.5 add-in, it won't compile.

So I can change the add-in to use .NET 4.0, which seems to work fine... is that ok (I would prefer to use .NET 4.0 if it is ok)? But the problem I am having is that after changing it to .NET 4.0 I cannot debug anymore. It won't hit break points or anything. The toolbar seems to be working as .NET 4.0 though. I know in the past I had a similar issue about not being able to debug and it was because the app.config did not specify the correct .NET version. But the config has:
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

So I either need to be able to use .NET 4.0 DLLs in a 3.5 add-in (which I???m thinking is not going to happen), or Debug with a .NET 4.0 add-in.

Any help is greatly appreciated. Thanks a lot!

*EDIT* I bet the debugging does not work because ArcMap.exe.config references <supportedRuntime version="v2.0.50727"/> ... hmmmm
*EDIT* Just confirmed the above edit... I can debug now. Is this ok? would we need to push this config change out to all our users too to make sure the .NET 4 code runs properly?

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

RichardWatson

I think that you are better off if you can stick with 3.5 because it is what ESRI supports and is certified on.

Can't get you get the external assemblies you depend on built on 3.5?

RyanCoodey

Thanks for the reply Richard!

Well, I likely can... the DLLs come from another team within our company but they have ported all their code to .NET 4 already. They won't like the idea that they have to maintain a 3.5 version for us to use, but I guess there isn�??t much we can do about it.

Technically speaking, running ArcGIS with the config set to .NET 4 should be fine... with the assumption there are no bugs with 4 being backwards compatible to 3.5, is that correct? And the fact that ArcGIS has not been tested with it. But I can see why that wouldn�??t be recommended.

I guess first step is to see what that DLL team�??s thoughts are.

Thanks again for the info.

JonHall

Ryan-
I had the same problem.
make a backup copy of C:\Program Files\ArcGIS\Desktop10.0\Bin\ArcMap.exe.config
close VS, then use a text editor to change it to match the exact version of .NET 4 you have on your dev machine.

I have v4.0.30319 on my machine
It won't work unless you match the exact number
Check your C:\WINDOWS\Microsoft.NET\Framework\ folder for the version

Change the start-up section from this:

  
  <startup>
    <supportedRuntime version="v2.0.50727"/>
  </startup>

to this:

  <startup>
    <supportedRuntime version="v4.0.30319" />
  </startup>

You may also have to set up the VS debugging symbol options...

The lack of .NET 4.0 support by ESRI has been blown out of proportion
It took awhile to configure due to misinformation (like "it's not supported"), but I'm using VS2010 with .NET 4.0 successfully now
Good luck!
-Jon

Ah, I see you edited your post and already discovered this last night! Another successful .NET 4.0 ArcGIS developer!

RyanCoodey

Hi Jon,

Thanks a lot for that info.

I have v4.0.30319 installed and have been running with:

<startup>
   <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>

and debuging seems to be working fine with that... not sure if that is a little more generic way to handle different 4.0.x versions. But if I run into any issues, I will try specifying the whole version (v4.0.30319).

Thank you much!

EagerIp

1. Debugging .NET 4.0 code in ArcMap.exe

You are correct that the .config file locks down Visual Studio on the target debugger type. That means if you want to debug .NET 3.5 code, you will have to update the .config file again.

A neat trick I learnt from a Visual Studio blog without changing the .config file manually is to add "ArcMap.exe" to your solution as an .exe project in Visual Studio using File > Open > Project/Solution, Select Exe project files (.exe) from the file extension filter.

Then you can switch the ArcMap project's debugging properties (open Properties page, Parameters > Debugger Type) to which ever target .NET runtime version you need. Of course, don't forget to set ArcMap.exe as your startup project before debugging.

Unfortunately, Exe project is not supported in VS Express editions so you have to manually edit the config file back and forth in such case.

2. Config file at deployment time...
Note that the startup supportedRuntime elements in the ArcMap.exe.config should only affect debugging experience in Visual Studio. At runtime, these xml elements are irrelevant to your custom managed COM ArcObejcts or Add-ins. They will run fine without adding any startup v4.0 element. The only requirement you have to check at deployment is whether the target machine has .NET 4.0 installed.

Hope these help.

RyanCoodey

Thats great info, thanks a bunch sorporbear!

MarkCederholm

Man, I'm glad I found this thread - I've really been banging my head over this one since I moved to VS 2010 yesterday. Isn't "upgrading" fun? 😛

OnumaTeawsakul

Thanks so much,

BingZhu

This method worked for me before. But when I use this in an add-in that I'm currently work with in debug mode, after ArcMap starts, when I click the add-in (tool), it doesn't go into the code.

Anything missing?

Thanks.

BingZhu

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.