hmstechsupport
asked on
WCF Service Issue (VS 2010 SP1)
Hi,
We're upgrading our environment for our ASP.NET / WCF application development from VS 2008 to VS 2010 (SP1). The solution compiles successfully on one machine which has just been upgraded from VS 2008 to VS 2010. Another PC, which has a new VS 2010 installation and has had no previous VS versions installed on it, fails to compile the solution. The error message is listed below.
Error 1 Reference.svcmap: Failed to generate code for the service reference 'WCFReportService'. Cannot import wsdl:portType Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Descri
Thanks,
Edward Lane
We're upgrading our environment for our ASP.NET / WCF application development from VS 2008 to VS 2010 (SP1). The solution compiles successfully on one machine which has just been upgraded from VS 2008 to VS 2010. Another PC, which has a new VS 2010 installation and has had no previous VS versions installed on it, fails to compile the solution. The error message is listed below.
Error 1 Reference.svcmap: Failed to generate code for the service reference 'WCFReportService'. Cannot import wsdl:portType Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Descri
Thanks,
Edward Lane
ASKER
@mas_oz2003
How would we tell what the third party component is? Also, what makes you think it is a third party component? The service it is complaining about is a very simple service with only 5 methods/contracts.
We know it is not a "Reuse assembly types" problem because that was one of the first things we tried and to no avail.
Thanks for the reply thus far!
How would we tell what the third party component is? Also, what makes you think it is a third party component? The service it is complaining about is a very simple service with only 5 methods/contracts.
We know it is not a "Reuse assembly types" problem because that was one of the first things we tried and to no avail.
Thanks for the reply thus far!
ASKER
Just to clarify further, we don't really make use of any third party tools/assemblies that are referenced with exception to 1 in particular that is installed on both machines (the assembly is a DevExpress assembly). Other than that we do not make use of any third party tools or components.
ASKER
Also, we have no issues updating or creating the web service references, the error only occurs when compiling the web site project.
Hard to tell without access to the code.
If your project is small I will suggest to:
- Create a new blank WCF project from scratch and then add your existing files.
- Test that the WSDL is generated OK
- And then replace the WCF project in your existing solution and build solution again
If your project is small I will suggest to:
- Create a new blank WCF project from scratch and then add your existing files.
- Test that the WSDL is generated OK
- And then replace the WCF project in your existing solution and build solution again
ASKER
We have narrowed it down to a method/contract that returns an inherited DataSet object (c#). When we remove the contract the issue is resolved. I can't imagine why one environment can serialize this object while another cannot. Any thoughts?
ASKER
On commented out the fore-mentioned method/contract returning an inherited DataSet object, the prior "Reference.svcmap: Failed to generate code for the service reference" compilation error message no longer appears. However, we’re now experiencing over 200 ambiguous reference compilation errors on classes that reference the same service.
Error 4 'EmployeeTimesheet' is an ambiguous reference between 'HMS.Utilities.EmployeeTim
Error 4 'EmployeeTimesheet' is an ambiguous reference between 'HMS.Utilities.EmployeeTim
Uhmm, now the problem is different, please answer the following:
q1. Where is EmployeeTimesheet defined on your project/solution for both updated and new PC? (Need that infor to answer q2)
q2. What is EmployeeTimesheet correct namespace? It seems you have some name space clashing.(hard to say if it was renamed by the tool or earlier than the upgradeand it was working by coincidence - anyway you must have only one reference - I will check that all your assemblies are having the same namespace)
q3.Is the solution in the new PC the same as the updated solution? In other words you updated the old VS2008 solution to VS2010 and then copy this solution or copy the VS2008 and run the update there. For the latter case use a comparison tool to find the correct differences.
Note: 1) Keep in mind that update tool is not 100% reliable.
2) Please upload your VS2010, I do not need the full details just the project and classes with method/property stubs and no dlls as you do not use 3rd party assemblies.
q1. Where is EmployeeTimesheet defined on your project/solution for both updated and new PC? (Need that infor to answer q2)
q2. What is EmployeeTimesheet correct namespace? It seems you have some name space clashing.(hard to say if it was renamed by the tool or earlier than the upgradeand it was working by coincidence - anyway you must have only one reference - I will check that all your assemblies are having the same namespace)
q3.Is the solution in the new PC the same as the updated solution? In other words you updated the old VS2008 solution to VS2010 and then copy this solution or copy the VS2008 and run the update there. For the latter case use a comparison tool to find the correct differences.
Note: 1) Keep in mind that update tool is not 100% reliable.
2) Please upload your VS2010, I do not need the full details just the project and classes with method/property stubs and no dlls as you do not use 3rd party assemblies.
ASKER
We currently have a Microsoft support ticket open on this issue. We will update this post after working with Microsoft.
Just to note, we have a working solution in VS 2010 in one environment and a non-working solution in another even though the solutions are exactly the same (shared via Source Safe). Even copying the folders from the working station to the non-working station does not help resolve the issue.
There is obviously a difference between workstation A (working) and workstation B (not working) but we cannot understand what it would be because the two environments look like they match perfectly. Perhaps it is something not registered in Visual Studio because perhaps we installed things in a different order, maybe there is a permissions problem, we simply don't know which is why we are left scratching our heads.
Just to note, we have a working solution in VS 2010 in one environment and a non-working solution in another even though the solutions are exactly the same (shared via Source Safe). Even copying the folders from the working station to the non-working station does not help resolve the issue.
There is obviously a difference between workstation A (working) and workstation B (not working) but we cannot understand what it would be because the two environments look like they match perfectly. Perhaps it is something not registered in Visual Studio because perhaps we installed things in a different order, maybe there is a permissions problem, we simply don't know which is why we are left scratching our heads.
ASKER
We have spoken with Microsoft and determined that the two machines are building differently.
On the machine that is working the App_WebReferences folder is not being validated/built as part of the build process.
On the machine that is NOT working Visual Studio is trying to build this folder and this is when the error occurs.
So the question we currently have outstanding is, how do we exclude the App_WebReferences folder from being looked at during the build process? Not even the Microsoft representative had a good answer for this.
One other thing I would like to look at is building the web references in a different way so we do not have to depend on Visual Studio App_WebReferences. We already build our endpoints at run-time (so that we do not depend on the web.config endpoints), so it would be nice to generate the proxies ourself and reference a DLL or something similar that we can reference (I believe this is called "contract assembly"?). What is the easiest way to make this change?
On the machine that is working the App_WebReferences folder is not being validated/built as part of the build process.
On the machine that is NOT working Visual Studio is trying to build this folder and this is when the error occurs.
So the question we currently have outstanding is, how do we exclude the App_WebReferences folder from being looked at during the build process? Not even the Microsoft representative had a good answer for this.
One other thing I would like to look at is building the web references in a different way so we do not have to depend on Visual Studio App_WebReferences. We already build our endpoints at run-time (so that we do not depend on the web.config endpoints), so it would be nice to generate the proxies ourself and reference a DLL or something similar that we can reference (I believe this is called "contract assembly"?). What is the easiest way to make this change?
The way to build the reference is using svcutils
You can either put the generated class in a separate assembly or App_code folder.
To avoid any mismatch issues you can run svcutils as part of you build.
Note: Make sure you run the right version svcutils:
http://stackoverflow.com/questions/2690966/svcutil-exe-for-net-4-0
You can either put the generated class in a separate assembly or App_code folder.
To avoid any mismatch issues you can run svcutils as part of you build.
Note: Make sure you run the right version svcutils:
http://stackoverflow.com/questions/2690966/svcutil-exe-for-net-4-0
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for hmstechsupport's comment #a38986113
for the following reason:
While working with Microsoft we have restructured our application to work around the issue.
Accepted answer: 0 points for hmstechsupport's comment #a38986113
for the following reason:
While working with Microsoft we have restructured our application to work around the issue.
You did not mention that the project was a web site one. My answer still holds because you can use the prebuild event to generate the WCF classes in your consumer web site using svcutils (I use a similar solution at work) . The key idea is not mix server/client code to keep the original architecture. (The author's solution reminds me how we used to solve remoting issues (.NET 2.0) when M$ did not have the excellent WCF solution)
ASKER
svcutil would not work in generating the WSDL because we had a custom typed DataSet object. Because of this typed DataSet object Visual Studio could not generate the WSDL and also this means svcutil would not generate it either (we did try with svcutil but it fails). So, your answer was not a viable solution for us.
This is why we converted to web application and reference the WCF classes directly, no WSDL generation needed, client and server are aware of these objects, no issues moving forward.
Thank you.
This is why we converted to web application and reference the WCF classes directly, no WSDL generation needed, client and server are aware of these objects, no issues moving forward.
Thank you.
Other possible areas to investigate, check:
http://stackoverflow.com/questions/3977560/service-reference-error-failed-to-generate-code-for-the-service-reference
VS2012 but the reuse types caused some issues in the past:
http://intelligenztech.blogspot.com.au/2012/07/vs-2012-rc-wcf-service-reference-failed.html#!/2012/07/vs-2012-rc-wcf-service-reference-failed.html