I have deployed a WCF service to Azure running in a web role. The Azure is stock standard (so runs .NET 4.0). I am getting the following error:
Type 'System.Threading.Tasks.Task' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.
My class library targets .NET 4
I have references to the Async targeting pack
It runs on my local machine via the emulator. My local machine is Windows 8 with .NET 4.5.
It seems to be similar to:
http://forums.lhotka.net/forums/t/11585.aspx
Is this possible, or do I need to get .NET 4.5 on to Azure?
In case the Task is being returned for an Async implementation (which is new in WCF 4.5), this was not supported in .NET 4.0. .NET 4.0 Supports IAsyncResult based Async.
The following applies if the Task was being returned as data (and not for Async):
Does your service returns a Task? That would not be right because a task is some 'work being done' - not 'data' as such. Maybe you tested the process in-proc and therefore it worked?
System.Threading.Tasks.Task is present in .NET 4 too. As the error says, the way your service is written, it needs to serialize a task, which is not possible practically. You should take a look at your service contract and the data types being used again.
Related
I am developing a WCF service (with .NET Framework 4.5), which should simplify the interoperability between clients developed in other languages and my SDK.
The problem is that when using the WSDL Importer providing the WSDL URL from service, it can only bring the Interfaces without any Type.
I tested with others URLs present in tutorials on the internet and the problem does not exist.
For example, when using the WSDL importer to http://www.webservicex.net/WeatherForecast.asmx?WSDL, Interfaces and Types are both brought.
The problem occurs even in a clean project Application WCF, testing with his IService1, and Service1 CompositeType (I'm using Visual Studio 2015).
In tests with Java clients, everything went well. But it was Java 8. Which leads me to suspect that it is a communication protocol version problem or something like this, but I can not know exactly where is the problem.
I would like to mimic the behaviour of a VB6-Active-X-Exe.
To do that, I have created a new project and set its settings to "COM Visible=True".
I can now add this .exe to my main application, and I can call it, call functions in that .exe, etc.
However, it is not really out of process, I think.
I would therefore like to investigate more about such an .exe's behaviour.
But I did not find any official documentation on it.
Can somebody tell me where to find more info?
Thank you!
Out-of-process COM servers (ActiveX EXE's) are not as easy to create with VB.NET as they were with VB6. When you reference a .NET executable (as a .NET assembly reference, not as a COM reference) from another .NET project, it always treats it as in in-process library. The .NET Framework has no direct equivalent to COM's out-of-process servers. Typically, in such scenarios, it is recommended that you create a WCF service, a web service, or use .NET remoting. WCF services are preferred since they use the most modern technology of the three.
However, since .NET supports COM interoperability, it is technically possible to create a .NET executable which can be registered as a out-of-process COM server. Then, when another .NET project references it via COM (rather than as a .NET assembly reference) it will run out-of-process. Microsoft provides an example of how to do that here.
However, if you don't need it to be COM (so that it can be used by non-.NET applications), I would recommend that you go the pure .NET WCF service route.
There is NServiceBus handler run on .net 4.0. I need to start it from VS 2008 project with 3.5 runtime (more specifically from SSIS 2008). The message to be send to the handler is parameter-less. What I tried:
I can not use NServiceBus API because of different .net versions, just can not add reference to the newer runtime library.
My other idea was to use NServicebus Gateway, but it turned out to be too difficult to run (xml+jsonp+get protocol with bunch of params) and lack of documentation.
Then I tried to send MSMQ message, but it did not work as well, because NServiceBus requires it to has special caption and extension message area which I can not specify, and it would be not reliable enough even if I could.
Are any other ideas on how to run simple parameter-less handler?
You can use the 2.6 version of NServiceBus which supports .net 3.5 - available here: http://www.nservicebus.com/Downloads.aspx
I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.
I have a service decorated as a singleton. It is hosted in IIS on my Windows 7 development machine.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]
Prior to the upgrade I had migrated all my projects to use VS2010, but stayed in .NET 3.5; I had verified that everything was working correctly.
After I upgraded all of the projects to use .NET 4.0, my WCF service started behaving incorrectly. Each call to the WCF Service creates a new object, which is clearly not how it is decorated (see above). I also upgraded the application pool to use 4.0 with an integrated pipeline (previously it was 2.0 with an integrated pipeline)
Has anyone experienced anything like this? I dont even know where to begin to troubleshoot this.
OK, I finally figured this out. We were using code the read the configuration, as well as created a compression channel based on code from Pablo Cibraro and Rodolfo Finochieti. Apparently, this code is not compatible with 4.0.
Once the compression and adhoc configuration reader code was removed, the problem went away.