I've got a .net 2.0 class library that uses .net remoting to communicate with a .net 2.0 server application.
I'm now creating a WPF version of the client and included the .net 2.0 communication dll.
The remoting no longer works (Exception Could not load file or assembly 'System.Data, Version=4.0.0.0,)
the line that fails is passing a DataTable as a parameter to a remote method.
The problem is if you use .GetType().Assembly it really does show that it's using the .net 4.0 System.Data assembly which the server obviously doesn't know about.
is there a way I can force the library to use .net 2.0 libraries for serialization?
This kinda depends on what type of configuration you're targeting, even if you run 2.0 and 4.0 in a mixed fashion this should be taken care by the run-time for you.
There seem to be a lot of components involved here, are you sure they are built using the correct frameworks?
If you build a WCF client on one machine and targets a different framework than the one installed on the machine that runs it it could lead to problems.
I'd like to know some more about your setup, specifically what projects you have and what "profile" these projects targets.
Meanwhile, you could try hooking the AppDomain.CurrentDomain.AssemblyResolve event and try locating the assembly yourself, it can work but it can also help to identify where in your code this problem occurs.
looks like your application was created as Framework 4 Application.
Check the settings of the project.
Related
I'm trying to use web services on unity.
I used svcutil to generate a proxy class, however the proxy class was using "System.Threading.Tasks".
I noticed that System.Threading.Tasks wasn't aviable on .Net 3.5.
So I went to player setting and I changed to .Net 4.x
But now I have an other issue, and I cannot find a way to fix it, I need to use System.Web.dll and System.Web.Services.dll to make my web service work, however, the dll that are include in Program Files\Unity\Editor\Data\Mono\lib\mono\2.0 are all targets for .Net 3.5.
So that mean I cannot use them on .Net 4.x
I've been looking for quiet long and was unable to find any answer.
I can add the code to the proxy class here if it's require, but I don't think it would be useful. Should I download those dll somewhere?
Anyone ever seen thoses issues somewhere?
You are using the wrong dll version.
Once you change Api Compatibility Level to Net 4.x, you have to copy the System.Web.dll and System.Web.Services.dll files from <UnityInstallationDirectory>\Editor\Data\MonoBleedingEdge\lib\mono\4.5 to your <Project>\Assets path.
That's it. Restart Visual Studio and Unity.
There is another method of linking missing libraries as described in this unity documentation.
Create a file called csc.rsp and put these 2 lines in it:
-r:System.Web.dll
-r:System.Web.Services.dll
And yes, you better set compatibility level to .NET 4.x
You also might want to restart Unity or VS in some cases.
I have a class library named WebAccounts.dll that calls some (of my own) WCF web services. I have the web services project automatically build a client version of its data contracts for consumption by its .net clients. It builds both a .net 3.5 and 4.0 version. So I have:
OMWebServices.dll
OMWebServices.ClientDataContracts35.dll
OMWebServices.ClientDataContracts.dll (.net 4.0 version)
As part of a new website we are building, I've upgraded WebAccounts.dll from .net 3.5 to 4.5. So I also updated it's ClientDataContracts reference from the 3.5 version, to the 4.0 version just because it could now use it.
Now when WebAccounts tries to call a service method, I get a MethodAccessException:
Attempt by method 'WebAccounts.Data.Franchise..ctor(System.String,
IdentifierType)' to access method 'WebAccounts.OMConfigService.ConfigurationServiceClient.GetFranchise(System.String,
OMWebServices.DataContracts.FranchiseIDType, Boolean)' failed.
If I change back to ClientDataContracts35, it works successfully. It is bewildering that changing my data contract assembly version affects whether or not my code can access the generated proxy method (which is not in the ClientDataContacts assembly, and is public).
I've stumbled onto this Question, which says that you can add <xmlSerializer useLegacySerializerGeneration="true"/> to the web.config to fix some kind of .net 4.5 serialization compatibility issue. I gave it a shot and it fixes it when using the 4.0 ClientDataContracts. But why?
One last twist is if I skip using WebAccounts in my website project and just add a service reference and call the same service directly, it works even with the 4.0 ClientDataContracts without needing to add the useLegacySerializerGeneration configuration. So using ClientDataContracts (4.0), the website can call the web service directly, but calling WebAccounts which calls the same web service gets the exception. I've also verified WebAccounts gets the exception when called from a test project to rule out anything specific to the website project.
Can anyone explain what's going on here?
In .NET Framework v4.5, XMLSerializer default implementation had been changed to dynamic code generation. The main benefit of this dynamic code generation approach is that it doesn’t require access to hard drive, which is one of the features that customers asked. However, its limitation is that it can’t access non-public members from other assemblies. This is why you see the MethodAccessException in some cases. For customers, who don’t need this dynamic code generation feature, can still use v4.0 serializer by using “useLegacySerializerGeneration” config switch as documented in [this blog post] (http://blogs.msdn.com/b/praburaj/archive/2013/12/06/xmlserializer-compat-switch.aspx). Basically, both serialization code paths are supported.
I cannot find in the documentation a way to start a XSocket server without using the PlugIn Framework.
I have a very easy library which contains its own controllers (located in the library itself) and which references XSockets.
I don't really need the PlugIn Framework and it is disturbing me because my library is located in a binaries folder with a number of other components that I don't manage. The PlugIn Framework is not working properly in such a complex environment and I'm quite sure it has to be possible to get an instance of the server singleton (new() is not working) without having to use:
server = XSockets.Plugin.Framework.Composable.GetExport<IXSocketServerContainer>();
thanks for your help.
My guess is this.
You have a non .net assembly in your bin folder. In XSocket plugin framwork version 1.1 there was a bug throwing an exception when trying to load an non .net assembly.
This issue is fixed in 1.3 (current version) and upgrading to XSockets 3.0.3 should take care of this issue.
Here is my dilemma:
The Problem
I have SubProgram (a DLL) that uses System.Data.SQLite and both are compiled to .NET 2.0
My MainProgram (an EXE) is compiled to .NET 4.0
My MainProgram loads SubProgram into a separate app domain and communicates with a proxy
Apparently, MainProgram is loading SubProgram and running it with .NET 4.0. This causes a known issue with System.Data.SQLite.
Now, I have researched and tried all the suggested fixes for the SQLite issue and the only one that worked was updating to the System.Data.SQLite assembly compiled using .NET 4.0 (see .NET 4.0 version at this link).
This would solve my issue only we have a strict set of rules for releasing and are not releasing SubProgram or it's dependencies in any way, therefore the System.Data.SQLite DLL that SubProgram is using must stay as the current .NET 2.0 version.
Question(s)
Is there a way to specify that MainProgram load and run SubProgram using .NET 2.0? Maybe something when setting up the app domain? So far I cannot find anything.
Is there another solution?
The only way you'll be able to do this is using cross-process communication rather than cross-AppDomain.
All AppDomains for a given application still run within the same process, therefore have to run within the same root CLR context (and same .NET runtime). But the .NET Remoting tech that would normally provide proxy communication and marshalling across AppDomain boundaries is also applicable with few modifications to cross-process communication.
If you change SubProgram to be a separate process, and add a Remoting channel between the two, this should be a reasonable way forward given your other constraints around releasing.
I have to give my customer my application. It's a simple application(3Mo).
I think it's really unnecessary to oblige my client to install the whole .NET framework (the 3.5) to work with a simple application (3 mo). I mean I'm sure that there is a way to avoid that, just include some dlls or something like that.
Well I have the dll in my project reference(LINQ dll, core Dll, system Dll, winfom Dll, office Dll and some other)
is it possible to give the application with those dll and that way I avoid installing the whole .NET framework?
Well I don't even need to make an MSI or setup project,
just give him the exe generated with Visual Studio and that's it.
I'm using VS 2010, C#, 3.5.NET
It's worth noting that Windows comes with various flavours of .Net installed depending on the version of Windows. If I remember correctly...
Win7 comes with .NET 3.5 SP1
Vista comes with .NET 3.5
XP SP2 includes .NET 2
Depending on your target audience you might find that this is good enough!
If these conditions are true:
a) you really want to avoid .NET framework dependency
b) it's a really easy/small application
Consider the option of porting it to c++
If not
use default framework (.NET 2, or 3.5 or 3.5SP1) that comes by default in windows as Dan Puzey said.
No it is not possible. Client has to install .NET Framework 3.5 (with SP1) redistributable package.
Edit: If you didn't want client dependency on .NET Framework you should choose another application type: Web application where .NET dependency is only on the server.
Most people have some flavor of .NET installed although most don't yet have 3.5. But you can create an installer that will download an install transparently to the user. Also if you target the Client Profile this dependency will be smaller.
Your client should have .net, there's no reason not to and if they haven't, they are a fool. Running XP with less than Service Pack 2 is dangerous. For the non-technically-inclined, compare it to using a van that's been subject to a manufacturer's recall. It may not necessarily be faulty, but the manufacturer has told you that it's no longer fit for use and are willing to make good at their own expense. As a responsible business owner, you wouldn't shirk that responsibility. In a similar vein, maintaining your Windows installation to the manufacturer's recommendation is not optional.
Have you considered making it a web app, with asp.net? The effort of porting should be less than a complete rewrite (depends on the applications functionality).