Attemp to parse version number from Action failed

Topics: Technical Questions
Jun 23, 2008 at 8:06 PM
I have been receiving the following error in the runtime log and can't figure out how to resolve it.  I've received the same error for different operations before.  Can anyone explain what causes this?

Communication error trying to call GetOperationVersionsForEndpointAndActionResult to catalog at address: [net.pipe://localhost/ServiceCatalog/Pipe] due to error [Attempt to parse version number from Action failed: Input string was not in a correct format.] with Action [http://tempuri.org/IUserPC/HasPrivilege] EndPointId [9460b15c-9db7-4917-ac37-78a8596c3e83] EndPointUri[net.tcp://appintg:10099/TitleCommon]
Developer
Jun 23, 2008 at 8:48 PM

Can you post the wsdl that was used to import your service into the MSE? 
I see the service implementation is net.tcp, what is the binding being used for the MSE hosted endpoint?

I've worked with you before, so I also want to clarify if this is occuring with the distributed solution (Broker on a different machine) or does this also happens with a runtime configured as Messenger+Broker?

Thanks.


kdstock wrote:
I have been receiving the following error in the runtime log and can't figure out how to resolve it.  I've received the same error for different operations before.  Can anyone explain what causes this?

Communication error trying to call GetOperationVersionsForEndpointAndActionResult to catalog at address: [net.pipe://localhost/ServiceCatalog/Pipe] due to error [Attempt to parse version number from Action failed: Input string was not in a correct format.] with Action [http://tempuri.org/IUserPC/HasPrivilege] EndPointId [9460b15c-9db7-4917-ac37-78a8596c3e83] EndPointUri[net.tcp://appintg:10099/TitleCommon]


Developer
Jun 23, 2008 at 9:37 PM

I can repro this issue if I manually add a full URI to the Action in the Serivce Tester.  For example, if I were to call the AddIntegers operation, the Action that is supposed to be submitted is "AddIntegers", howerver, if I replace this with something like "http://tempuri.org/AddIntegers"  This error will be generated.

The wsdls published for the endpoints hosted by the MSE shouldn't have the full URI as part of the soapAction for each operation.  If it does, then this will probably be filed as a bug.  However, if the full URI for the Action was manually provided by the client application then it ought to be removed.

 

Jun 23, 2008 at 10:17 PM
Ok, I was able to figure it out based on your explanation.  Our client was using a proxy generated via svcutil against the underlying WCF service instead of directly against the MSE exposed service.  svcutil put the full name in the action and I had just changed the binding and endpoint address to call MSE.  Thanks for pointing me in the right direction.
Aug 11, 2009 at 6:53 PM
kdstock wrote:
Ok, I was able to figure it out based on your explanation.  Our client was using a proxy generated via svcutil against the underlying WCF service instead of directly against the MSE exposed service.  svcutil put the full name in the action and I had just changed the binding and endpoint address to call MSE.  Thanks for pointing me in the right direction.

We have services for which we do not want to emit metadata. We create access assemblies that have WCF hooks built into them, but they are not exposed to the consumer. I need to use the VS2008 service reference capability for development of that assembly. However when deploying, obviously I will not be pointing to a design time address and need use the endpoint that is exposed via MSE. I even tried referencing the MSE metadata reference, but it was not anything close to what the WCF service exposes. So, I guess the question is, how can I reference the WCF proxy in development and switch to the MSE endpoint for deployment?

I did change around some of the action settings, and got past the action failed exception, but then of course the contracts, etc do not match.

Developer
Aug 11, 2009 at 10:33 PM

I'd like to answer initially around a broader concern regarding the expectation that the virtual service exposed by the MSE is a 1:1 correlation to whatever implements the service logic... albeit with the exception of the soapAction as has already been discussed.

While this 1:1 correlation may be valid (and even more so for a newly developed 1.0 service implementation), our view is that there should be no expectation of this direct correlation.  The virtual service can and will often be exposing operations from different implementations over different protocols (HTTP, HTTPS, TCP) and message versions (POX, SOAP11, SOAP12, etc).  And will use different contracts.... what if the resource the MSE is virtualizing isn't even a web service?

Now more to your question.  The developer trying to consume a service should be unaware of whether or not the service is virtual.  In the case of the access assemblies you mention, the development of those should leverage "add service reference" pointing to the virtual service.  This assumes there is an MSE instance in place within the development environment.  For this scenario it ought to be ok (at least temporarily) to allow the virtual services to expose metadata (or publish to a UDDI registry where a WSDL can be retrieved from) within the Development environment so that you can create the access assembly as needed (you'd need to do this anyway even without the use of MSE).  Once this is performed, there should be no issue going from development to deployment since the access assembly already has the proper contracts.

As a developer trying to create a service, there would likely be unit tests that hit the service directly, but ultimately it should be imported into the MSE and consumers under development should reference a virtual service that exposes those operations.  Note that this gives the service developer the added flexibility of creating a new service (2.x), importing it into the MSE, and applying a policy to map the original consumer requests(1.x) to the new implementation without those consumers even knowing about it.  Then as consumers reach a convenient development cycle, they can re-generate their development proxies to pull in the new 2.x contracts to benefit from whatever the new functionality is.

I think what is a bit more difficult than it should be is the ability for a developer within a development environment to be able to re-import their service overwriting whatever resource and contracts existed previously... this is akin to going from Alpha 1 to Alpha 2 where you really don't care about how to transition possible consumers or map the differences between the contracts... this is a seriously breaking change which we try to prevent in the solution but from a pure development perspective causes the developer to have to do a few extra steps.

Service Virtualization is a key aspect to the MSE that breaks this 1:1 expectation even during the development cycle.  Using the MSE only in the final "production" environment is going to be fought with challenges as you have already encountered.

We are interested in more feedback on this and how to improve the developer experience (pre-deployment of a service).