ThinkGeo.com    |     Documentation    |     Premium Support

Excetpion when using the .net Framwork 4.0

#1

Hello,


 


I am trying to create a new project based on .net framework 4.0, and i added your WPF Desktop Edition Map Control to a new Window.


It is working perfectly until a click on the "Full Extent" button on the navigation pane, and this exception is thrown:


Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.


 note that i added two layers: the first is an ecw raster layer, and the second is a shapefile feature layer


How can i solve this problem.


Thanks.



#2

Taking advantange of this thread, I would like to ask if you have plans to target the .net framework 4.0 in a near future.

#3

XTeam, 


Add the following section to the app.config file of your application will solve the problem. 
 

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>


 
Carlos,  We will find what's the best way. As we have some legacy users they might keep using 2.0 environment, it's good if we can update to 4.0 while don't affect the old users. Thanks for the remindings and any suggestions are appreciated.
 
Thanks.

James,



#4

Thanks all, 
 We are really working on .net framework 4.0 from a while.

#5

2.0? isn’t it targeted for 3.5 sp1? (WPF) 
  
  As you have the build process quite or compleately automated, wouldn’t it be possible to have the source in 3.5 as today, and build as today, but run a an additional batch to build targeting 4.0?, I mean not using any new feature of 4.0 but targeting for it as well. 
  
  Daily builds would have 3.5 and 4.0 folders for each assembly set. 
  
  The key difference here is that 3.5 offline installer is 250Mb while 4.0 is just 30Mb

#6

Carlos, 
  
 Thanks for your post and suggestions.  
  
 Our daily build only provides the .net 3.5 framework target (MapSuiteCore is .net 3.0), while I think your suggestion is interesting. I think we probably will consider it in the future as more and more customers are using the .net 4.0 framework, for now, please use the solution provided by James. 
  
 Any more questions please feel free to let me know. 
  
 Thanks. 
  
 Yale 


#7

Hi Yale, 



I upgrade my solution to .NET Framework 4.0, and it seems to work even without the configuration above. Why it does fail for XTeam and work fine for me? Should I include the useLegacyV2RuntimeActivationPolicy clause anyway? 



My actual supportedRuntime config in the app.config is:





<startup>
 <supportedruntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client">



#8

Hi Carlos,
 
Here are answers for your questions:



1. Why it does fail for XTeam and work fine for me? 
 
There are some mixed assemblies (containing both unmanaged machine instructions and MSIL instructions) in XTeam’s project, these assemblies can only be loaded into .NET Framework 4 or later when useLegacyV2RuntimeActivationPolicy is true.
 
2. Should I include the useLegacyV2RuntimeActivationPolicy clause anyway? 
 
You don’t need to set useLegacyV2RuntimeActivationPolicy to true if your project doesn’t refer to mixed assemblies, the default value is false.
 
Regards,
 
Ivan

 



#9

Hi Ivan, 
  
  Thanks for the answer, now I have it clear. Just one more question; are FdoExtensions assemblies mixed? Or said in other words, I don’t have any own mixed assembly, is there any MapSuite assembly mixed?

#10

Carlos, 
  
 All FdoExtension assemblies are on .net 2.0 framework, MapSuiteCore.dll is on .net 3.0 framework, WpfDesktopEdition.dll is on .net 3.5 framework. 
  
 I think one assembly can’t call mixed, only two or more assemblies could be mixed. 
  
 Thanks, 
  
 James

#11

Hi James, 
  
  What I mean is that FdoExtension assemblies stored on %SYSTEM32% are unmanaged, so I need to know if they are considered mixed, or as they are referenced from FdoExtension.dll that wraps them, I can consider all the code manager. 
  
  Said in other words; Should I set the useLegacyV2RuntimeActivationPolicy If I use FdoExtension, considering that I don’t have own non-managed assemblies?

#12

Hi James, 
  
  What I mean is that FdoExtension assemblies stored on %SYSTEM32% are unmanaged, so I need to know if they are considered mixed, or as they are referenced from FdoExtension.dll that wraps them, I can consider all the code manager. 
  
  Said in other words; Should I set the useLegacyV2RuntimeActivationPolicy If I use FdoExtension, considering that I don’t have own non-managed assemblies?

#13

Carlos, 
  
 Thanks for your quick response. 
  
 Set the useLegacyV2RuntimeActivationPolicy is only when your application’s target framework is 4.0 and you reference the 2.0 assembly. Now, I let you know the FdoExtension is 2.0, so if your application is 4.0 you need to set it, if not you don’t need to do it. 
  
 Feel free to let me know if you have questions. 
  
 Thanks, 
 James

#14

Hi  
  
 Its well over a year later. Is there any word of when the requirement for the 2.0 assembly will be removed? 
  
 regards 
  
 Murray

#15

Murray, 
  
   Our guidelines for upgrading version of the framework are that we stay compatible to one version previous to the current version.  Currently framework version 4 is the current one so we need to stay compatible with 3.5.  Of course the new framework version 4.5 is in RC and should drop anytime now.  Very quickly after that we will upgrade our support to version 4.0.  Internally we really want to upgrade to version 4.0 as it has so many goodies in it such as MEF, threading improvements etc. however we have allot of current customers to consider on compatibility.   
  
 Here is a link to this on our wiki but it basically says what I mentioned above. 
  
 wiki.thinkgeo.com/wiki/Map_Suite_Release_Cycle_Guide#Framework_Compatibility 
  
 David

#16

Thanks David 
  
 that makes sense. 
  
 However isn’t this is version 2 not version 3.5 requirement. 
  
 Also Mef is very nice :) I am one customer who would not complain about version 4 only support!

#17

Murray, 
  
   I thought this issue was because we were not 4.0 and upgrading to 3.5 would not make a difference.  If not then I will see if we can upgrade the framework version to 3.5 across the board.  The only thing is the development team may want to wait until we can move to version 4 as version 4.5 is right around the corner.  Let me check and can you 100% verify that going to 3.5 will fix this issue? 
  
 As for MEF, it just really opens the door to plugins where it would be to hard for standard object oriented practices.  For example after we have MEF we can introduce a replaceable geometry library, a plugable decimal degree math library, new ways to handle logging and exceptions.  In my mind it allows us to cross cut into our API to add new plugins.  We are using it extensively in our soon to release GIS editor and it rocks. 
  
 David