I have two WCF services, one for reading operations and the other one for writing operations.
Although they are doing different operations, both of them are sharing the same classes (through a DLL reference to other project wich supports the model of the problem).
My problem is that, when I try to add both services to my C# project I can't share the same namespace:
Cannot create a service reference with namespace 'X' because the name
is already in use by an existing service reference, folder or file
If services are placed in different namespaces, classes are different and duplicated code grows a lot.
Is there any solution?
Edition: Very similar to: Two WCF services with different contracts but same business objects . No solution anyway.
If you use VS 2010 (probably works on 2008 also) click advanced button in "add service reference" window and use "reuse types in specified referenced assemblies". You may have to move generated types to other assembly depending on how your project look like.
Related
I'm new to programming so I might not be using some of the correct terminology. I'm running into an issue with InteliSense when calling a C# class from another project within the same solution. It's not suggesting a using statement and is instead trying to get me to create a new class inside of the current project which is not what I want. I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
I looked at some of the documentation online and nothing has helped so far. InteliSense appears to configured correctly to suggest using statements. It provide suggestions just fine. I've been able to create lists and then use it to add the proper using statement along with some other things. Just doesn't want to work with anything inside the solution. I've been following a couple of different tutorials including, .net core 2.1 and 3.1, inside MVC and Razor page projects along with a couple just straight C# console apps. It doesn't work in any of them when I start adding multiple projects to the solution and try using classes from outside the current project.
I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
That is the correct behavior. In order for ProjectB to use classes defined in ProjectA, you must first add a reference to ProjectA. Just having the projects in the same solution is not sufficient.
The purpose of having multiple projects in the same solution is simply for grouping related code. The projects may or may not actually depend on each other. For example, a web application may have a separate projects for the actual web UI (the pages themselves), a data access layer, unit tests, maybe some class libraries for shared code used by multiple projects, and maybe even console applications (or some other project type) for performing backend administrative tasks. In this scenario, the web UI and console applications may have references to the data access layer project and/or the class libraries. The unit test project will have a reference to the web UI project, and so on. The dependencies are one-way - you may not have circular references (the unit test project has the web UI project as a dependency, but not the other way).
Our customer sent us a WSDL file for their web service API. We used Visual Studio's "Add Service Reference" to consume it.
However: we only want to generate a service proxy, not the data contract classes. We want to reuse classes we already have within a referenced assembly.
How to instruct "Add Service Reference" to not create Data Contract classes?
...or how to instruct WCF to use our Data Contract classes from the referenced assembly instead?
This comes down to the following options on the Advanced... part of "Add Service Reference":
which also map to the /r / /reference option in svcutil.exe.
This defaults to enabled, so if it isn't working: there's a good chance your types are not exact matches. The easiest way to ensure exact matches is to reference the same library dll from both projects, or worst case the same .cs file (a dll reference would be preferable, IMO). The data-contract namespace and name are the usual culprits here, and must match exactly (as must the members).
Add your data contract classes (or even better create a new library for you data contract classes and reuse both in the service and client side) to the project including your service references. When adding a new service reference or updating an existing one, select "Reuse Types in Referenced Assemblies".
This is old but I have one doubt about this.
I can access classes when adding service reference, this is ok
I can't see these classes when working with all projects inside the same solution in Visual Studio and adding "project" references.
Is there a way to test client side code using all projects inside the same solution in Visual Studio?
thanks
I'm working on a WCF service. The WCF service interface and implementation are in separate projects. There's also a Windows service project to host the WCF service.
One of the things the WCF service implementation needs to do is call out to several external (SOAP) web services. The way we typically structure this is we create a separate class library project for the SOAP service(s); we'll create a Web reference and a factory/helper method in the class library.
The above detail may or may not be pertinent to the real problem. Which is that I get an error when building the WCF service implementation project (where X is one of the SOAP service wrapper assemblies):
referenced assembly 'X' does not have a strong name
But the WCF service implementation project isn't set to be signed (nor is the interface project). And at this point the only two things referencing it are the Windows service project and a unit test project -- and neither of those is signed either.
The WCF implementation also references other (pre-existing) web service wrapper projects, but it's only complaining about these two. I've pulled up an existing and a new project file in a text editor side by side... And I can's see any significant differences.
I've also checked whether any of the projects is importing a setting that requires it to be signed, as described in Stack Overflow question Remove signing from an assembly. That doesn't appear to be the case.
I was attempting to use AutoMapper -- 1.1 since we're still on .NET 3.5 -- in my WCF implementation. That is a signed assembly, so I can see where it might have a problem reflecting on my code and the SOAP service wrappers. But it seems to me that would be a run-time problem, not build time. But because I suspected it might be at least a contributing factor, I removed AutoMapper and the dependent code but I still get the same error.
I have researched the issue, most of the search results consist of instructions on how to sign (possibly third-party) assemblies.
I've tried removing and re-adding the references, restarted Visual Studio and my PC.
Visual Studio 2010 / .NET 3.5 on Windows 7 64-bit.
I'm sure I'm missing something fairly obvious ... I just can't figure out what.
Well ... this is embarrassing.
As I suspected, it was something simple. The service interface and implementation were in fact set to be signed; I was incorrect about that. However, this was done not in the project settings/file, but in the AssemblyInfo.cs file, via the directive
[assembly: AssemblyKeyFile("keyfile.snk")].
I was not familiar with this method of signing. I gather it's been deprecated since VS2005 -- partially because it's more straightforward to manage signing via the project properties, partially because putting this information into the AssemblyInfo is considered a security risk.
And I had in fact looked at at least one of the AssemblyInfo files ... but apparently I didn't scroll down far enough. (I said it was embarrassing.)
Hopefully someone else can benefit from this.
You can not reference an unsigned assembly from a signed assembly, the project which fails to build should be the one that has a strong name key tied to it.
It is possible that you have a signed version of one of your references in the Global Assembly Cache that MSBuild is picking up instead of the reference you selected.
I just inherited a SharePoint project that I want to refactor and take all the common/reusable code and place it in a seperate project within the solution. The solution already has several projects, and almost all of the projects have dependencies between one or more other projects in the solution.
I want all of the depencies (SPMetal classes, static methods, utils, etc) to be put into one project so that there is only one reference needed for common code (and no code clones)
I refactored the project, and now I am trying to deploy this code to the SharePoint server (Both my local dev server through VS2012 and to the production server through WSPs). I initially tried to add the Common.dll in all of the other project's "Additional Assemblies" list (in the Package file), but this has caused all of the WSPs to fail deployment with the following error:
Cannot add the specified assembly to the global assembly cache
This is because the Common.dll is in use by the owstimer and some other services and can't be removed.
My next thought was to deploy the code as a feature and then make all of the other features dependent upon it, however, I don't know how to do this. Is there any way to have a feature that only contains classes?
Is there a better way to make common code available to multiple SharePoint projects?
Based on error it looks like you did not strongly signed the "Common.dll" assembly. As result it can't be installed in the GAC.
For brevity purposes, this post relates to ambiguous references in a Silverlight Page.XAML.CS file, whose project contains a service reference to a WCF service and a MyClass.cs file added as a 'link'. The Solution contains the Silverlight Project and a Web Project that contains a WCF service and a MyClass.cs file (along with the aspx files etc).
For some reason I am getting ambiguous reference errors once I add the service reference to Page.xaml.cs. Prior to adding the using statement for the service ref, I had one for MyClass.cs (which remember had been added to the SL project as a link) to the page, and it was running fine. Once the SVC ref is added, the compiler complains about ambiguity in my call to any class / property in 'MyClass.cs, such that a reference to MyClass.Class becomes ambiguous to 'ServiceReference.MyClass.Class...Seems very strange to me.
Assumptions & Clarifications
I ensured that no namespaces, class names, methods or variables had similar names
WCF service must reside in web application to have access to other non Silverlight assemblies etc
Other .cs files in the Silverlight project reference MyClass.cs, otherwise I would have simply removed the link to MyClass.cs, and allowed referenced MyClass.cs through the service ref.
My assumption here is that this has something to do with adding a file as a link? Any KungFu Masters out there able to offer some insight as to why this is occurring, alternatives to adding as a linked file, other ideas?
Is MyClass a class used by the service for which you added a Service Reference? If true, then there are two versions of each class in MyClass.cs: one from MyClass.cs, and one from the service reference.
You should pick one or the other - either use the service or don't use the service.
If you've added "MyClass.cs" as a link in both your Silverlight and Web projects then it will most likely cause a name collision, fortunately they should be in seperate namespaces. The linked class will be in the original namespace and the one generated by the Service Reference will be in the generated namespace.
You can use the "Reuse Types in Referenced Assemblies" option when generating the Service Reference so that the generated service proxy uses your linked class rather than generating a new one. There are however a couple of tricks to get this to work correctly, I outlined these in a post a few months ago Resuing types in Silverlight Service References.
I hope this helps.
Nigel Sampsons Answer led me in the right direction, thanks a million!
The Solution
Create a new project for the class file, and add a reference to that project in your Silverlight Project. Then when you ad your service reference and select "Reuse Types in Referenced Assemblies", it will not generate it's own implementation of the class, eliminating the ambiguous reference.
Unlike a typical client / server service scenario the class file must be compiled seperately for Siverlight and ASP.NET.
I've been able to overcome this issue by simply un-checking the re=checking
"Reuse types in referenced assemblies" when I configure the service reference. I was getting ambiguous references between the Class Library and the service reference which resulted in what I refer to as a cascade of errors, growing with every move I made.