I have seen this question before (here for one), however the solution is to not reuse referenced assemblies.
I need to reuse included assemblies because multiple services reference the same shared Objects.
If I do not reuse the assemblies I get namespace errors because the same Object is referenced through
different namespaces. (ie. Service1.Object, Service2.Object)
In short, I need the generated Client class that extends the ClientBase for the web service but I cannot untick the reuse referenced assemblies as I need shared Objects with the same namespace. Any suggestions?
You can generate your client proxy with svcutil.exe and use the /r switch to specify assemblies that you want referenced instead of re-emitted in the auto-generated client proxy code.
ProjACommon
ProjBSvc
References ProjACommon
ProjCClient
References ProjACommon
You want a client that references ProjA types and/or code rather than them being auto-generated into a new namespace within C
After building ProjBSvc exec the following, which outputs .wsdl & .xsd
svcutil.exe ProjBSvc.dll
2nd consume the wsdl & xsd to generate a proxy/client:
svcutil.exe *.wsdl *.xsd /o:<ProjCClientPath>/Client.cs /r:ProjACommon.dll
ProjCClient references Client.cs generated from previous steps
Build and examine with the object browser and you will see the types in C referencing the types in A instead of new types with the same name in C's namespace.
You may want /tcv and /n as well as other switches to meet your needs.
Here is an article that may help. It also links to the Microsoft documentation for svcutil
Use a mapper, meaning you will have to duplicate the models(objects) and have a class the maps the objects from one namespace to the next.
Related
In Visual Studio you can add a link to a source file in another project. Is there a way to enforce preventing any changes from being performed on the linked source file (ie: link them into a project as 'read only', so as to prevent accidental modifications by folks who don't realize they are linked, and not local to the project)?
I have two projects, one of which is a DLL, the other is an EXE. The DLL contains a Windows ServiceInstaller and ServiceBase classes. I link these classes into my EXE (there are multiple flavors of the EXE) from the DLL in order for the EXE to be installable as a service and for me to not have to replicate the ServiceBase and ServiceInstaller in all of the EXEs. I do not however want to inadvertently be able to make changes to the linked classes from within the context of the EXE project.
Not via some Visual Studio-supported mechanism, no.
IMHO, as a general rule you should not be using a linked file like that. Yes, the feature exists in VS, but for the very reason you mention as well as others, it's a great way to create code maintenance headaches.
Note that your own scenario could be just as easily solved by exposing shared types in an assembly and referencing that assembly from those that need them. I.e. just reference the DLL from your EXE and use the types as compiled into the DLL rather than having the EXE define new versions of the types using the same source code.
Visual Studio does not have a way to set a "read-only" attribute for a linked file, but in general, linked files cause more problems than they solve.
Generally speaking, the preferred method for code reuse is to put the classes into a DLL and then reference those classes from the EXE - but in your case, the ServiceInstaller and ServiceBase classes have to be present in the EXE in order for the Windows service mechanism to pick them up.
Instead of linking the files, you could create base classes that inherit from ServiceInstaller and ServiceBase and put those in the DLL. Then add new classes into the EXE that inherit from your custom base class (which contains most of the logic). This way, all of the shared code gets pulled in from the shared DLL, but the EXE(s) still contain the classes necessary for the Windows service to start.
I'm trying to add an external service reference in a C# .Net 4.0 project where the service wsdl contains a type called "System", which results in something like this:
As you can see, everywhere in Reference.cs where the "System" namespace is referenced, it instead believes it to be this System class instead, resulting in errors all over the place.
What would be the best way of resolving this naming issue?
You can rename the generated System class (and all references to it) in the Reference.cs file, then add a [XmlRoot(ElementName = "System")] attribute to it so it will be (de)serialized properly.
You'll of course lose these changes when you regenerate the proxy.
I have a project which has a reference to a "Utilities" project. The "Utilities" project references a 3rd project. All have the same namespace, but I can't do a "using OurNamespace.Utilities.3rdProject" from the main project.
I need to keep it so that all other new projects, only has to reference the "Utilities" project and have access to all other namespaces referenced through it. I can't include all the references on all projects.
/edit (it cascades sort of)
Main Project (references Utilities)
-- Utilities
-- Project with same namespace referenced by Utilities
In Main project, I now need to be able to access the namespace in the project that is referenced within Utilities reference, but without adding it to the main project exclusively.
Edit
"Project 1" references Utilities
using Utilities.Namespace1;
Within Utilities another project is referenced with Namespace2
I want to now access Namespace2 from "Project 1"
using Utilities.Namespace2;
Without having to exclusively reference BOTH in "Project 1" seeing as there will be multiple projects referencing Utilities
If you want to directly use components of an assembly in another assembly, then you need a reference. By "directly" I mean in a strongly-typed way, e.g.:
Creating an instance of a type in the other assembly.
Handling instances of types in the other assembly.
In contrast, "indirect" use is if the Utilities assembly uses the components of 3rd project in the background, but does not publish these e.g. through public properties, arguments of public methods and so on.
To clarify further on assemblies and namespaces: one does not reference namespaces, but assemblies. Namespaces are only used to make type names unique. Namespaces and assembly names are completely independent from each other from a technical perspective (though it is good practice to start the namespaces with the assembly name). So having the same namespace in two assemblies, does not change the situation in any way; if you want to use the types of the other assembly, you still need a reference.
In order to solve your issue, you can either add the reference to 3rd project or if you can't do that, do one of the following:
Add wrappers in the Utilities assembly for the required functionality in the 3rd project. As you already have a reference to the Utilities assembly, you can access these wrappers - as long as you do not access the types of 3rd project directly.
Create another intermediate project that contains the wrappers and reference this.
I have WCF service responsible for exposing services and connecting with local database MSSQL.
I generate client of this service in a few projects, e.g. Proj1 and Proj2. In Proj3 I have references to Proj1 and Proj2. I want to use types from database, but they are in different namespaces (Proj1.ServiceReference.TablePerson, Proj2.ServiceReference.TablePerson).
How can I resolve this problem? I suppose using sth like converted/adapter for each type (table) is not the best solution.
Have a shared dll with your classes and reference it form the server and from the client.
When you create a wcf reference, make sure that "reuse types from existing assemblies" is set. This will make generated proxies rely on the shared dll code and WILL NOT create new proxy types each time you create a web reference.
What you should do is create a separate project to create your service references in, and then have Proj1 Proj2 and Proj3 all reference that project. That way you will only have to generate one set of classes for your service reference.
I have a WCF service library and another library that has a service reference to it in VS2010. "Reuse types in all referenced assemblies" is selected on the reference properties. When I scope in the client proxy namespace in the consuming library code, I get this error:
WCF Error 'Exception' is an ambiguous reference between
'System.Exception' and 'My.Namespace.CoreService.Exception'
... where My.Namespace.CoreService is the namespace of the service reference. My service library does not define a type called Exception; the line in question is a catch block for the built-in Exception type.
Strangely, when I added the service reference, four datasources were automatically created in the consuming project for built in types (System.Data.DataSet, System.Data.DataTable, System.ServiceModel.Channels.Message and System.Xml.XmlElement). These four types are used as return types in some of my OperationContracts.
Based on this it seems to me that the built-in types aren't being reused across the assembly boundaries. This doesn't make any sense to me, can anyone help?
Thanks
Do you have a type in the generated proxy code called exception (something the service was using as a type in its contract)? If so, you will have to fully qualify the types or use aliases
You can check to see the generated code my clicking on Show all files in solution explorer and opening up the service reference and reference.svcmap until you see reference.cs - this is the generated proxy code