We are hosting a WCF service in IIS. For tracking purposes we need to know the version of the service that's being hosted in IIS.
This service is part of an suite of services so we implemented all common functionality (Like the mentioned tracking service in a common library)
When trying to get the Assembly version using normal calls
Assembly.GetExecutingAssembly()
Assembly.GetExecutingAssembly(): get the version of the common Library
Assembly.GetEntryAssembly(): null
Assembly.GetCallingAssembly(): get the version of the common library
I also tried getting the call stack and getting the last one (got the IIS version).
Does anyone know how to programmatically get the version of the WCF service that is hosted in IIS?
I am assuming that you need to get the WCF service's version from within common library dll that is referenced by the WCF service at runtime. If not, I don't understand why you would get the common library assembly by running Assembly.GetExecutingAssembly().
If that is the case, then you want to find the assembly containing the Application object that IIS is running. By using the standard reflection methods on that root Application object, you should get a reference back to the dll that IIS is executing, which should be the WCF service.
Documentation for Application class:
http://msdn.microsoft.com/en-us/library/ms525360(v=vs.90).aspx
This looks like a promising way to get it:
http://msdn.microsoft.com/en-us/library/system.windows.application.current(v=vs.110).aspx
When talking about versions of WCF services, more likely you will realize you want versioning of Web services, rather than assembly version, though you mix both in your question.
The assembly version is of implementation details, and there are no legitimate case that you need to expose such implementation details through either Web services or IIS. IIS itself is of deployment detail, and has nothing to do with versioning of Web services.
System.Windows.Application is of WPF, has nothing to do with WCF or Web service.
When you learned programming, probably you had learned the once an interface is published, you should never alter it, though you could change implementation or introduce new versions of the interface. a Web service is basically an API or interface through http binding, and the description language is typically WSDL for SOAP base Web service.
In a nutshell, versioning of Web service is done through Xml namespace, and in .NET, you could have a mapping between XML namespace and CLR namespace. During deployment, you could have multiple versions of the same service being hosted in the host, so legacy clients could consume the legacy services, and new clients could consume the new versions. So you will have seamless transition strategy.
There's no direct link between assembly versions and service versions, and you should not expose assembly versions, since the clients say PHP or Java clients do not know what assembly version is.
For more details of starting points, here are a few good links if you google "Web service versioning":
http://www.ibm.com/developerworks/webservices/library/ws-version/
http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html
http://msdn.microsoft.com/en-us/library/ms731060(v=vs.110).aspx
Related
I'm following the documentation on Consuming a WCF Web Service and need clarification on how best to do this in a Classic Xamarin (not Xamarin Forms) solution that uses a .NET Standard library.
Specifically, I need to understand whether separate API calls must be wrapped in the interface class e.g. ISoapService so that they can be made asynchronously? The project already as an auto-generated Reference.cs class that documents all the available web service endpoints. Does the interface class need to include all potential API calls?
How do ensure that my interface class is properly referenced from the Xamarin.Android and Xamarin.IOS projects? Is there something specifically required aside from referencing the .NET Standard Project from the mobile projects?
I've looked high and low for WCF web service integration with Classic Xamarin but have not found any helpful samples Any links would be helpful.
I have a web site and would like to expose certain functionalities using WCF.
Before deciding which type of WCF project I need to use I wanted to compare the differences between WCF Class library and WCF application. I know this question has been asked many times and answered many times and the answers are usually about different hosting options each one offers but I wanted to try and see the differences, so this is what I tried:
Step 1 - In a same solution, I have created a WCF Service library project and created Client console app project, set the console app as a startup project, referenced the service library project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
Step 2 - In a same solution, I have created a WCF Service application project and created Client console app project, set the console app as a startup project, referenced the service application project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
On both steps after compiling the solutions I was able to copy the client app's exe and the service dll's to a different location and still be able to run the clients.
Based on this little excercie I am confused about the hosting part. It seems wether I use WCF Class library or WCF application type I get the same result.
This is just like using multiple projects in a solution, you reference one from another and use the methods, there must be something I am missing which highlights the differences between the two and highlights the benefits of using WCF, also in the past I remember I had to add a service reference to the clients apps in order to consume the service, why is this not the case here?
Thanks
1) Running a wcf service application allows you to provide communication into a single application, where you have a single instance of a thing you want to provide access to. Maybe this is a game, or a chat room without an external state engine or datastore. This is useful for providing diagnostic information about an application you might have written for example. I used this to provide external control for an industrial robot that I wanted to provide remote control access for.
That is to say, that you write an application, it has a function. You want to expose part of that functionality to remote applications. You do this by adding a WCF endpoint to your existing application, so your application itself is controlling the WCF hosting elements, lifecycle of the endpoint etc.
2) Running a WCF Service is for when you've got an external data store, or your service is stateless. A translation service, lookup service and web page requests fall into this category.
With a service class, you're saying here is this service, this thing that provides a function. It isn't tied to the lifecycle of another application or process and is typically hosted by IIS. IIS manages when the class is loaded and run based on the requests that come into it. These services have no internal persistence and rely on an external datastore, or are, by nature, stateless (think of a postcode lookup, or a calculator service)
It sounds like you're actually adding the projects as references, rather than connecting to them as services. That is to say, that the consuming application is actually loading the service as an assembly (in the same application/ memory space) rather than as a separate application/ service that your application then uses WCF to communicate with.
The WCF Service Application template can be used to create WCF services with a hosting website created within the project
The WCF Service Library template can be used to create WCF services that are hosted by the WCF Service Host, and these can be tested using the WCF service Test Client.
the biggest advantage of using a standalone library (apart from decoupling the logic) is that you can easily migrate your service, i.e. host it in another application or another type of application. E.g., let's say you're hosting your service using IIS - you can easily move your service to a standalone application, etc.
I have a requirement that I need to be able to have a stand-alone version of application, as well as an online version. One possible way of doing this would be to have a WPF version, which would satisfy stand-alone, and an MVC Web version.
Obviously, that would require two code bases (though admittedly they should be identical except the front end code). Is Web API self-hosting stable enough that I could just host a full-blown web app inside of it if I needed to?
Web API can run selfhosted but for running ASP.NET (MVC) you require a server like IIS (Express).
What you can do is have IIS Express installed on a machine, host your Web app in that and have Web API self hosted if needed. Of course if you already have IIS Express installed you might simply want to opt to run everything in it: both Web app and Web API.
Provided you're ok with using both internal/external apps using the same database/service you could host a single version of the WebAPI server in IIS, and simply use it for API Controllers.
You could then use two identical ASP.Net MVC sites (rather than Desktop & Web), which make calls into your WebAPI service. One hosted on the intranet, one on the internet - both hitting your WebAPI for business functionality & data persistance.
The goal here is to reduce the amount of code maintained. Essentially, it's two projects - your WebAPI project, and an ASP.Net MVC site.
I use Web API for self-hosting a number of projects that are in production. The web site http://www.hypermediaapi.com is a self hosted Web API.
No need to have two or more code bases for this scenario. What you need is a library what provides the API for your applications. The library can be used directly in the standalone application what I assume is a desktop app.
You can then create a WCF or Web API or even both layer what isn't anything more than a wrapper around the same library. The WCF/Web API contracts can be the same as your DTOs so the WCF service implementation would be something like this:
SomeObject IMyService.DoStuff(string param)
{
var myLibrary = new MyLibrary();
var someObject = myLibrary.DoStuff(param);
return someObject;
}
The only overhead would be that when an interface changes in library the changes have to be repeated in service interfaces too, but no actual business logic would be duplicated.
You can even share the interfaces, i.e. the API would expose the same interfaces what are implemented by the WCF service if you don't mind having the contract attributes on library interfaces.
Can I write a web service that implements the same methods and returns the same custom objects using both C#/WCF and also Java Web Services? And if so, can I then access the web services using a single web reference but with different addresses?
I'm asking because I have to host a web service that has a GetCitations and GetTerms method for publically exposing our database content. We are on IIS, so I was going to do it with WCF. However, other partners in the project also have to host an equivalent service and they are all Java based.
We are then building a software app that needs to connect to any number of these services (as defined at runtime by a user). I am expecting that we can have one set of classes to connect to these services (but with different endpoitn addresses), but am not sure whether I'm right in expecting this to work.
Is this possible?
And what considerations/restrictions are there?
Thanks.
It shouldn't be a problem, if you make sure that both services have equivalent wsdl files and you use http/soap binding.
I am not sure about using the binary (net.tcp) one with WCF, though. It might be a problem.
One way to do it is to use JAX-WS (Java 6) to expose a method as a web service.
The JAX-WS stack allows for automatically generating the correct WSDL at runtime.
The .NET team can then take that WSDL, and use standard tools to create a mock implementation of that WSDL. This mock implementation is then used as the actual .NET implementation, and you then use standard tools to generate the WSDL for that web service.
You now have to web services with the same semantics each with their own WSDL.
Both Java and .NET can implement a SOAP compliant web service, so the answer is yes, you can write a .NET and a Java webservice that implement the same WSDL.
I'm about to start building WCF web service, and i would like to structure solution in such way that is would be:
Easy to develop - i would like so that developers on my team could just get sources, build, and start service, probably best would be to have possibility to start it as console app?
Easy to host this service later in IIS, WAS or windows service.
I was thinking about having this projects:
Shared (for web service interface)
WebService (for actual implementation of web service and svc file)
ConsoleHost (for hosting web service in console app)
Will there be any problems with such approach?
What could be things that i should consider in advance?
Maybe there is better structure?
I would appreciate any insights and links to resources that could help me chose right structure.
p.s. web service itself is simple, but this approach would be reused for more services.
What I tend to do is to place all my interface definitions in one assembly/project, all the service implementations in another assembly project, and the hosting environment, whether it be console, IIS (ie the .svc files) or windows service or whatever, in a separate assembly.
With this information, I say this structure looks fine.
You might also consider creating a separate ServiceModel assembly to store all your custom behavior and WCF. They could then be reused for other projects