We have a ASMX Web service 2.0 which was created way back and some of our applications still use it. Now we want to add another webmethod to it and I am not sure what effects it may cause with existing clients / apps. Or what precautions I should take while doing that.
I would appreciate your views.
Adding new methods should not cause any problems for the existing clients as long as the interface (signature, web service namespace) of the existing methods remains unchanged. Of course, existing clients cannot call the new methods, but the old ones should work as before.
Though adding methods works, there are explicit ways to version the interface of an ASMX web service. See this link for details.
Related
As I know Microsoft.Owin.Host.SystemWeb allows me to run OWIN app on IIS, but today I found another package called Microsoft.Owin.Host.IIS that (as I understand from it's name) has similar purpose.
Actually I think that I am wrong and that packages are very different.
So, here the questions:
What is the difference between that two packages?
In what case should I use one or another?
And last (optional): can someone give me a link to good explanation of all that ASP.NET 5 mess? (Microsoft creates new platforms/frameworks/features faster than document them, so I am feeling quite disoriented now...)
To answer your optional question:
The problem with System.Web is that it is way too bloated and coupled with IIS. As an example, you cannot host an MVC website in a Console Window. You are forced to run it in IIS. The OWIN initiative is an attempt to modularize and decouple the Web Stack by adding abstraction.
In essence, the entire Web Stack is reduced to a pipeline of middleware components (similar to the way node.js does things). A middleware component or AppFunc (Func<IDictionary<string, object>,Task>) is a function that takes a context (containing request, response and other things...) and does something with it (request parsing, routing, rendering a view, logging stuff, ...). The entire stack then becomes a sequence of middleware components: every component calls the next one in the chain, or breaks execution by not calling the next one.
ASP.NET 5 is a natural evolution in the sense that it builds upon OWIN and as such enables modularity and removes the dependency on System.Web (and IIS). Everything is now opt-in and you can even run applications cross-platform (using .NET Core). This would never be possible without OWIN.
Microsoft creates new platforms/frameworks/features faster than document them
The concurrent development of MVC 6, Katana (OWIN) and ASP.NET 6 isn't really helping to clear the confusion between all that's going on.
As far as I understand it:
The Microsoft.Owin.Host.IIS namespace, assembly and package are for Helios, introduced in this blog post. Basically it's meant to run managed code, without ASP.NET, in IIS - to provide your own OWIN middleware on top of that.
So you seem to need Microsoft.Owin.Host.SystemWeb for your purposes. This forms an OWIN host that allows your middleware to use System.Web.
We have an application that uses webforms for some older web app pages, but also contains MVC functionality for some of the newer features. We have some new requirements for downloading files that will have to be processed on the server (not direct links to static files on the web server).
I haven't seen anything to indicate if there is a reason one should use an ASHX handler over just using an MVC controller and operating on the response object and returning EmptyResult() at the end of the action method.
Is there a best-practice for this with MVC? Should ASHX handlers be left for WebForms or is there some benefit they provide over using MVC for this type of file download feature?
The performance of HttpHandler is better since it is more bare-metal than MVC actions (just a few extra steps, but still).
Besides that, I see no reason why you should choose one over the other for performance reasons. MVC has some nice features you might want to use, like caching and authorization attributes.
If you choose to use MVC, use results that are specifically built for file handling, like FileStreamResult or FileContentResult.
Well, an ASHX can be a bit more contained and specific... however, there is something to be said about having all your code and logic in your main application.
There is no technical reason to do one over the other, to my knowledge with MVC nowadays. With WebForms it was harder to stream large files, but with MVC you can do that pretty easily (so you don't have to load the whole file into memory first). Also, given modern Async methods you don't have to worry so much about tying up worker threads and what not for scalability.
It's really up to you. Even if you wanted to separate it into its own module, nowadays it might make more sense to make it an owin module rather than an ashx. It's more about how you want to design your app.
I am newbie in webservices of .net, i am implementing a project of .net with backend in webservices as i got impressed with the benefits and portability of this architecture.
But the confusion is, i want to know the way i am adopting is right or wrong. I have made services with in my project and calling them from code behind classes, where as my service is implementing the database code. I am attaching the screenshot for further explanation.
Not really, when you do this you are calling the classes directly rather than as a service call. This is liable to cause you issues (e.g. if you set up one of your methods to return a certain HTTP response status for example).
If you don't want this to be a service call, then you would be better extracting the logic from the service method into a business layer and have both the service and your page call that code.
If you do want a service call, then you need to add a service ref to your project that points to the service and call it through the generated proxy.
Your approach makes no difference of using a C# class vs using a webservice.For this approach You can use a class instead of a webservice.
Use web services instead of C# classes for the following cases.
You want to expose some functionality to outside world/consumers/other applications
You want to decouple parts of your system so that they can be changed without affecting other parts of application
You want to do make your application scaleable, so you create webserices and deploy those on different servers
I have a web service and a client. The classes used in parameters and return types are in a common DLL shared by both. However, whenever I update the web reference, visual studio generates copies of the classes with the same names and public properties and methods. Then the solution won't compile because the client code tries to use the versions in the common DLL. I can solve the problem by deleting the "duplicate" classes every time I update the web reference, and adding a using statement to point at the common dll's namespace. Is there a way to fix this permanently?
UPDATE: See my comments below. This is a "feature" of asmx web services. There is no way around it other than one of the following:
1) Use a more modern type of web service.
2) Don't use a common DLL
3) Manually fix every time you update the web reference, as in the original question above.
This is a "feature" of asmx web services. There is no way around it other than one of the
following:
Use a more modern type of web service.
Don't use a common DLL
Manually fix every time you update the web reference, as in the original question above.
Sources: Other stackoverflow questions:
"Reuse existing types" is ignored when adding a service reference
How does Visual Studio 2008 and svcutil decide which types to re-use from referenced assemblies when generating a web service proxy class?
I had the same problem, but I had neglected to add the reference the correct assembly with the request/response types in my client. Once I added that reference, and ensured that the "Reuse types" checkbox was on in the Add Service Reference dialog, it worked properly.
There`s no way to do that.
However, I think we have a design problem here. When we create a web service, we expect that our clients don't need to reference any dll from us. Only the types exposed by the web service should be enough for their use (web services are all about interoperability, imagine your client app written in Java, you can't reference the .NET dll).
That's why these types are created when you reference a web service. In my opinion, you should only rely on the classes generated by the web service in your client app. Remove the reference to the shared dll from the client project.
This doesn't direct answer your question, but provides an alternative for your issue.
In the domain class, set AnonymousType=false to prevent generating class with prefix unexpected when adding the web reference
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType = false)]
but this only ensure that the class, auto-gen in Reference.cs has the same structure as the domain class.
A way to walk aroud this is to serialize/deserialize to the domain object.
I would like to implement the MVC pattern to an existing Flex project. I want to separate out the controllers and models from the views. They currently all live together in large mxml files.
My question is, should httpservice requests be in the model or the controller? What sort of advantages/disadvantages would there be to either?
I normally try to abstract any service request into a Command call (execute, result, fault) which gets the service it needs to called injected in (which can be a good idea to abstract even more and be a service delegate).
There's a good example of how to use short lives command objects in Parsley's dev manual (one of the more popular frameworks).
I would rather approach the services as something totally different - an MVCS, not just MVC. You should check the Introduction to Flex Application's Architecture I wrote in my blog.
I looked at httpservice, and it seems to me that, while the service itself might reside in a repository or Service Layer (between the controller and the model), using the service involves references to UI elements such as DataGrid. So the implementation of that service probably would occur in the controller, or even in a ViewModel object.