Let me briefly explain my architecture before I ask my question. I have a client application that calls out to a web service and passes it a couple of items of data. The web service uses this data to do some lookups and then returns a binary serialized object, by using the BinaryFormatter, as a byte array to the client. The client then deserializes the object and uses it. My problem is I had to rename the assembly that the server uses for the new version. This has caused a problem when deserializing in the client. It is not an option for me to deploy a new client just so the new assembly name can be used so my question is, is there a way I can change the Assembly Name that is being written during serialization. I know how to use SerializationBinders for deserializing but that does not solve my problem as that would require deploying a new client.
I am currently using C# 2.0 for both the win forms application and the web service.
If I were using .NET 4 the solution from Thomas would have been perfect. However, .NET 2.0 does not provide this functionality. Instead I just renamed the dlls back to what they were. I would like to eventually rename the dlls but at this point I have not found a viable solution where I would not have to deploy something to the client as well.
You can recreate an empty assembly with the old name containing just the AssemblyInfo.cs, where you put a type redirect:
[assembly: TypeForwardedTo(typeof(MyClassName))], for every type that is moved to another assembly. Ofc this assembly should reference the new one.
But generally consider not using binary serialization for complex data structures, because it's not friendly to such changes as moving types between assemblies.
Related
Consider the following Visual Studio project structure
ProjectA.csproj
AClass.cs
ProjectB.csproj
References
ProjectA
Web References
AWebService
AWebService.csproj
References
ProjectA
ReturnAClassViaWebService.asmx
The issue occurs when ProjectB adds the web reference to AWebService and automatically generates all the proxy code for accessing AWebService including a new implementation of AClass. Since all of our other code needs to use the AClass defined in ProjectA, we're forced to convert the AWebService.AClass returned from the service into something we can use.
We're currently considering two solutions, neither of which are ideal.
Manually editing the generated Reference.cs to remove new definitions of AClass
Serializing AWebService.AClass to a stream then deserializing to ProjectA.AClass
Does anyone have any better solutions? This seems like something common enough for other developers to have experienced it.
Ideally we would like to have the proxy code generated in ProjectB to reference ProjectA.AClass rather than generating a whole new implementation.
Our environment is VS 2008 using .NET 2.0.
I have had the same problem that you are describing and I have tried both of the options you specify without being entirely happy about either of them.
The reason we both have this issue is at least partly because the shared-library-between-consumer-and-provider-of-a-web-service-solution is in violation of accepted patterns and practices for web service design. On the consumer side, it should be sufficient to know the interface published in the WSDL.
Still, if you are prepared to accept a tight coupling between your web service provider and web service consumer and you know for certain that your current client will never be replaced by a different client (which might not be capable of referencing the shared library), then I understand why the proposed solution seems like a neat way to structure your app. IMPORTANT NOTE: Can we really honestly answer yes to both of these questions? Probably not.
To recap:
The issue appears when you have classes (e.g. a strongly typed dataset) defined in some sort of shared library (used on both client and server).
Some of your shared classes are used in the interface defined by your web service.
When the web reference is added there are proxy classes defined (for your shared classes) within the web reference namespace.
Due to the different namespaces the proxy class and its actual counterpart in the shared library are incompatible.
Here are four solutions that can be tried if you want to go ahead with the shared library setup:
Don't. Use the proxy class on the client side. This is how it is intendend to be done. It works fine unless you simultaneously want to leverage aspects of the shared library that are not exposed by the web service WSDL.
Implement or use a provided copy/duplication feature of the class (e.g. you could try to Merge() one strongly typed dataset into another). A Cast is obviosuly not possible, and the copy option is usually not a very good solution either since it tends to have undesirable side-effects. E.g. When you Merge a dataset into another, all the rows in the target dataset will be labeled as 'changed'. This could be resurrected with AcceptChanges(), but what if a couple of the received rows were actually changed.
Serialize everything - except for elementary data types - into strings (and back again on the consumer side). Loss of type safety is one important weakness of this approach.
Remove the explicit declaration of the shared class in Reference.cs and strip the namespace from the shared class wherever it is mentioned within Reference.cs. This is probably the best option. You get what you really wanted. The shared class is returned by the web service. The only irritating drawback with this solution is that your modifications to the reference.cs file is lost whenever you update your web reference. Trust me: It can be seriously annoying.
Here is a link to a similar discussion:
You can reuse existing referenced types between the client and service by clicking on the 'Advanced' button on the 'Add Service Reference' form. Make sure the 'Reuse types in referenced assemblies' checkbox is checked and when the service client is generated it should reuse all types from project A.
In past versions this has not always worked correctly and I've had to explicitly select the shared type assemblies by selecting the 'Reuse types in specified referenced assemblies' option and then checking the appropriate assemblies in the list box. However, I just tested this with VS 2008 SP1 and it appears to work as expected. Obviously, you need to make sure that the types that are being used by the service and client projects are both from project A.
Hope that this helps.
We encountered a similar problem with one of our projects. Because we had several dependencies, we ended up creating a circular reference because project 1 required objects from project 2, but project 2 could not be build before project 3, which relied on project 1 to be build.
To solve this problem, we extracted all the public standalone classes from both projects and placed them inside a single librarie. In the end we created something like this:
Framework.Objects
Framework.Interface
Framework.Implementation
WebService
The WebService would be linked to all projects in our case, whereas external parties would only be linking to the objects and interface classes to work with. The actuall implementation was coupled at runtime through reflection.
Hope this helps
I am trying to write some code in C# that will call a WCF service on the fly by importing the WSDL, examining it and then making calls to it dynamically.
The service I am calling can change from time to time - so if it does I want my client to know about new methods and new input parameters and output parameters to the calls, without rebuilding my client.
One possible solution to this is to import and compile a service reference on the fly.
Outlined here: Creating an assembly on the fly from a WSDL
I would like to avoid the generation of an assembly and then reflecting over it if possible.
I looked into the code of the dynamic proxy in the link and they use a framework class to do the import. This class is the WsdlImporter. So I had thought great - I can use that and examine the WSDL schema and determine what calls are present and what inputs and outputs are available.
The problem is that the type information is missing in the MessagePartDescription objects that the WsdlImporter creates. Apparently this is missing because it cannot find the types yet - see the response to the question from Brian.
So any advice on how I should proceed? Am I completely on the wrong track here?
This is probably not an answer but I will post it as one to fully describe my opinion.
Dynamic proxy:
IMO this is example of wrong usage of technology. It is elementary behavior of WSDL - if it changes you have to change client or you have to make good WSDL versioning and create new client.
You still have to somehow say your client to get WSDL - does it mean that you will parse WSDL before each call? Doesn't seem like a good idea.
Information about types is really not part of WSDL because by default WSDL is generated as interoperable. CLR types are not operation needed for interoperability. When you create service proxy by Add service reference or Svcutil it will generate code for types defined in WSDL. That code then need to be compiled.
You can try to use NetDataContractSerializer instead of default DataContractSerializer. NetDataContractSerializer adds CLR type information into WSDL but I still expect that new types must be known to your clients - it means deploying new assembly with types and use it by clients. This almost sounds like same approach when simply deploying assembly with new static client proxy.
Dynamic WF client
I also don't see too much usage of this architecture - you still need to change client to reflect new WF steps, don't you?
Changing the WF
Are we talking about Windows Workflow foundation? I can hardly imagine scenario where you create WF, expose it as a service and then change it. When you expose WF as service you are probably defining long running WF. Long running WFs use persistance which is based on serialization (at least in WF 3.5 but I believe it is same in WF 4). When you change WF definition, all persisted WFs are most probably doomed because they will never ever deserialize. This situation is usually solved by parallel deployment of new and old version where old version is only used to finish incomplete WFs. Again it means new clients.
If you look at the problem from a different angle. Do you need to regenerate the proxy each time or do you need a contract that continues to work when things change?
WCF has a mechanism for this IExtensibleDataContracts see: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx
Best practices for versioning of contracts can be found here
I have a Silverlight Class Library that I want to use in both my Silverlight and my WebService project.
I am able to create and reference the Library in both projects without any problems, but when I try to use any of the classes in the Library on the Silerlight project, I get an ambiguous reference error between my Library and the Asmx Webservice (apparently, the silverlight project believes that the classes in the class library exist in the webservice).
How can I correct this issue? I have tried rebuilding and cleaning, but it does not seem to work. Can anyone help?
Sounds like the objects you are passing to Silverlight, via the WCF service, are the same objects in your class library. In that case the generated web-reference objects will be given the same names. Linking with the library will then give you 2 sets of objects with the same names.
If you install RIA services, once feature is the ability to share code between client and server by simply adding ".shared" in the class filenames before the extensions. ASMX services are so last century :)
if you don't want to learn the RIA services way of sharing objects across the great-web-divide (which I would recommend), you need to separate the data objects from the functionality you actually want to share client and server side.
To give more specific advice on your current set-up I would need to see more about how it is structured.
A technique you can use is aliasing your using statements:
using MyNameSpace = My.Name.Space;
using MyWebService = My.Web.Service;
Then access all of your objects with these aliases to remove the ambiguities.
I have seen examples where you can pass parameters between aspx and silverlight app as well as how to pass simple values back to aspx.
Is it possible to pass generic types such as list collections from a silverlight app to a asp.net page to be picked up. I have looked at serialization but not sure if this is the best approach due to performance?
Thanks in advance
You can also communicate with your .aspx page client-side, through scriptable objects... see HtmlPage.RegisterScriptableObject(string, object) in Silverlight documentation.
Since Silverlight is client-side and ASP.Net is server-side, you will need to use serialization in order to pass objects between the two.
I would consider using the DataContractSerializer in Silverlight to serialize the object as XML. You can then push the XML up any way you want: ASPX web service, WCF service, HTTP PUT, Hidden fields in the HTML, etc.
Review:
Sharing C# code between Windows and Silverlight class libraries
Your Answer will be listed within that solution already provided for the same question or nearly exact.
Excerpt:
You cannot set a reference from a Silverlight assembly to a regular .NET assembly but you can do so the other way round.
So create a shared Silverlight assembly and add your code to that assembly. Now you can set a reference fro both your regular .NET and you other Silverlight assembly to the shared Silverlight assembly.
The restriction is that you can only put code in there that would work on both the .NET and Silverlight CLR but that is no different from sharing code.
Courtesy: Maurice
I am writing a Large Scale Silverlight Application.
I am currently writing the data retrieval elements.
I have now encoutered and issue.
I have a common Project that hold objects, this project is referenced by both the UI and the WCF service.
The UI requires INotifyPropertyChanged for binding purposes.
Now the WCF must use the same objects, but I am getting a compiler error saying
"The type
'System.ComponentModel.INotifyPropertyChanged'
is defined in an assembly that is not
referenced."
EDIT: The error is in the WCF service.
I want one object class, how do I solve this problem?
diagram http://www.pcbuyersguide.co.za/picture.php?albumid=19&pictureid=1708
Thanks
-Oliver
If you plan to use the same source code for your Entities (domain) for both a clr and silverlight project you will need to use 2 projects because the Silverlight assemblies are not the same as CLR assemblies.
Add a Silverlight Class Library project to your solution, the name is not important but I usually just use XXXX_SL.
Now, you will 'Add Existing Item' all of the source files from the clr project, but notice the dropdown on the open or select button? click that and 'add as link' or whatever it says there.
You are now using the same source for both projects and your solution will compile.
There may be some minor tweaks along the way but that will set you on the right path..
Here is some reference material
did you add a reference in the compiling project to System.ComponentModel
I found a method here that allows one to create the CLR classes on the service side and then one can use the generated objects from the Service Reference as the classes are generated with the INotifyPropertyChanged and ObservableCollection.
This solves the immediate problem of the client/server boundary but does fit into my solution because in order to use the generated objects you need the service reference. But I have a ProxyClass that does the talking to WCF so there I cannot see a way of passing these object types back to the ViewModel.
I see some people have written mapper classes, but this is far from ideal as I would have to write 3 classes for each POCO object (client class, server DTO class, mapper).
Any more suggestions?