I have developed a WCF service that has been working fine for a few weeks now. I publish this service to IIS directly from the development server. I have a dev test app that includes this WCF service as a Service Reference in its own project.
My WCF class library also references another project within the Visual Studio solution, and many classes are in the referenced project that are used by the service and calling applications.
Today, after publishing some changes to the service (I did not make ANY changes to the referenced project or its classes), three of about 20 of the classes in the referenced project are no longer in the service reference of my test app. I cannot use them in code any longer, and they are no longer in the Reference.cs. I double checked, the classes in question are still decorated with [DataContract] and the properties are all still decorated with [DataMember] in the service solution.
Everything is building in Visual Studio OK.. I have rebuilt and republished everything, the missing classes are set to compile, I have tried IIS resets, completely deleted the IIS site and did a clean republish, no avail. I have tried deleting the service reference on the test app and getting a clean proxy every time as well. Nothing is working.
I then tried making a dummy class in the referenced project and built it in. Republished the service again, and even this dummy class does not appear in the Reference.cs. I am at a complete loss as to why these classes are not included in the .dll for the referenced project after it is published as it is evident that everything is building OK in Visual Studio.
I face such problem.
Following steps help you
1. Right click on Service ( In Service Reference Section of Project)
2. In Update Service Reference click on Advanced
3. Do as attached image.
Wanted to come back and post what was causing my problem:
I had made changes and none of my service methods used the 3 "missing" classes as a return type or parameter anymore. I simply had to un-comment the methods that used those classes to make them usable again. Makes sense now but I was convinced something else was wrong.
I faced similar issue and resolved it by doing the following.
Add the address of your end point with mexHttpsBinding.
E.g., Lets consider the address as mex.
While configuring service reference append /mex at the end of your service URL.
https://service.domain.com/serivce1.svc/mex
This will enable metadata exchange. So Reference.cs will be modified / added (if you are adding service reference for the first time).
Please Make sure that your service has an end point with mexHttpBinding / mexHttpsBinding
Edit : On analysis I found that this issue happens when the service is exposed via more than two end points (including mex end point)
Related
My project has a bunch of projects and some of them consume a WCF one that is in the solution... Every now and then I have to update the service reference and i always get the same message saying that the server actively refused to answer as if there was no service there...
First I start debugging only the WCF project and test it using the WCF Test Client, and everything is fine...
Then, I open another VS instance, without closing the first one, open the same solution (again, not closing the first), start the WCF project, go back to instance 1, and update the service reference without a problem...
I think this is not how it's supposed to work... why can't VS start the WCF project, update the reference and then go on its way? is there a config i'm missing? perhaps something that another team member might have screwed-up in the past?!?
Details:
VS 2015
All projects on the same solution
All projects using same framework version
All projects using same architecture ref (x64)
In your situation (WCF project part of a solution including service consumers) I would not use a service reference. Service references are designed for when you are calling a service over which you have no control and to which you have no access.
You can call the service directly using ChannelFactory<T>.CreateChannel() - this removes the need for service references altogether and makes your code simpler and more readable.
I've been trying to create a webService on a .NET platform using Visual Studio's WCF Service Library project template. I noticed that when I tried to use a VO object from another project file within the same solution... programatically, the compiler has no issues and runs fine... but when I call the webService, it will stop the application prematurely.
I've done some google-ing and the closest answer I could find was the possibility that since WCF is run from a separate location, the VO.dll file that I added in as a reference is not available to it.
As a reference to the above statement... please find the enclosed link:
http://forums.asp.net/t/712261.aspx
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'm trying to reference my domain service by following this documentation.
The following two declarations work fine
xmlns:riaControls = "clr-namespace:System.Windows.Controls;
assembly=System.Windows.Controls.DomainServices"
and
xmlns:data = "clr-namespace:System.Windows.Controls;
assembly=System.Windows.Controls.Data"
but I'm having problems with this one
xmlns:domain="clr-namespace:SNMPApplication.Web"
This error appears, even after I rebuild the whole solution:
Undefined CLR namespace. The
'clr-namespace' URI refers to a
namespace that is not included in the
assembly.
I've tried adding a reference to my Silverlight project but I get this error
You can only add project references to
other Silverlight projects in the
solution.
Does anyone have an ideia of what the problem is? :/
Thank you so much in advance.
The way you add a reference to a RIA DomainService is not through the traditional Add Reference dialog. You do it through the project settings. In the Silverlight Application, goto the project settings, specifically the 'Silverlight' tab. On that tab will be a 'WCF RIA Services link'. You'll be able to select your project that contains the DomainService.
After you select the project, Visual Studio will generate code for your Silverlight application. This is found in a Generated_Code folder (which isn't visible in the project, though you can see it in the folder). This is where your code that you need to reference will be.
If you genuinely need to access the Web project from your SNMPApplication project, then I think what you'll need is either of the answers to this question: How to access web application class into silverlight application
You are not actually creating a reference to your web project when you do this, it resolves it at compiletime to create the generated g.cs files (I suspect), This is one of those magic things that does stuff in the background ( I think it stores it in your project file and you set it in the project properties --> silverlight tab under WCF Ria Services link).
Please check the following:
Your SNMPApplication.Web is in the same solution as your Silverlight project (SNMPApplication)
and that your reference is the same as your DomainService class namespace you added to your web.Project class (It might be in a sub folder and that is why it's not working,
If you haven't created a domain service please add one as this is what silverlight and ria services uses to connect between your entity model and silverlight. (Have a look here from Adding a DomainService class
xmlns:domain="clr-namespace:SNMPApplication.Web"
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.