none
CLR loading 4.0 system assembilies for none 4.0 built assemblies. RRS feed

  • Question

  • Hi All,

    We have a client/server application which talks via remoting.  In our client application we have started migrating to .NET 4.0, at the moment only our plugin's use 4.0, none of the core of the application.  This means the application must support both 4.0 and 2.0.  In our app.config for the client we added:

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

    Our server-side executable is completely built in .NET 2.0 which no references to 4.0.   We found when the client passes a dataSet to the server via the remoting connection, it is using System.Data.dll version 4.0.0.0.  This is causing an issue on the server side since there is no .NET 4.0 installed.  The question is, why does the client want to use a version 4.0 DataSet when the assembly in the client is built against 2.0 and is there anyway around this behavior? 

    We can make everything work by installing .NET 4.0 on the server and adding the same startup section above to the server app.config.  We need to explain why a customer needs to install .NET 4.0 on ther server when the server application is only referencing .NET 2.0.

    Any help would be greatly appriciates.

    Thanks!

    Wednesday, October 27, 2010 2:07 PM

Answers

  • > We need to explain why a customer needs to install .NET 4.0 on ther server

    Basically, remoting is a very leaky abstraction.  It has been superceded by things like WCF which are much sturdier in this regard.

    You might be able to work around this by plugging things into the deserializer on the server.  I think this has something to do with hooking into the "binder" of the deserializer (http://msdn.microsoft.com/en-us/library/ee358766.aspx). You can do this in managed code, it probably isn't too hard.  Check with the Serialization Forum to find people knowledgeable.  That being said, I don't know if this is wise -- I don't see a reason to think that the serialization data would be backwards compatible.  4.0 is a major release.

     

    • Marked as answer by SamAgain Friday, November 5, 2010 11:15 AM
    Thursday, October 28, 2010 12:18 AM

All replies

  • > We need to explain why a customer needs to install .NET 4.0 on ther server

    Basically, remoting is a very leaky abstraction.  It has been superceded by things like WCF which are much sturdier in this regard.

    You might be able to work around this by plugging things into the deserializer on the server.  I think this has something to do with hooking into the "binder" of the deserializer (http://msdn.microsoft.com/en-us/library/ee358766.aspx). You can do this in managed code, it probably isn't too hard.  Check with the Serialization Forum to find people knowledgeable.  That being said, I don't know if this is wise -- I don't see a reason to think that the serialization data would be backwards compatible.  4.0 is a major release.

     

    • Marked as answer by SamAgain Friday, November 5, 2010 11:15 AM
    Thursday, October 28, 2010 12:18 AM
  • Thanks for the information.  I'll create another thread in the suggested forum.

    Although serialization and remoting could be the problem what we really need to understand is why the application is using System.Data 4.0 when it is referencing the 2.0 versions.  Simply adding 4.0 as a supported runtime in the startup section of the config file causes the code at runtime to load 4.0 assemblies regardless of which assemblies we built against.  Could there be a binding redirect happening?  If so is this configurable?

    Monday, November 1, 2010 1:30 PM