Since 2011sp1 Tridion comes with a precompiled core service client. Would there still be a reason to generate your own proxy by adding a service reference? Or is that older method officially deprecated now?
Let's take a look at advantages of compiled dll vs service reference:
Core service is growing and it's quite a problem to generate service reference reference on slower network. The bigger core service will be the harder it will be to generate service reference (there are workarounds of course)
Compiled dll is compiled using "correct" settings. There are some options you can set when generating service reference, like return types and types to be reused from other assemblies. By using compiled dll you are sure that you get everything right.
You can get quite a mess with you app.config when updating service reference. I think updating dll and config is a bit easier.
It's tricky to generate service reference when you have LDAP or SSO or HTTPs configured
The precompiled coreservice client is distributed by default to help implementers. As generating the own proxy is bit difficult (you might need to change some config in svcutil).
The precompiled coreservice client always uses the latest endpoint. Depending upon your situation you might need to generate your own proxy if you want to connect with the old endpoint always.
Otherwise you can use the precompiled client which will make sure you are connecting to the latest endpoint but that might break your client (you might need to fix something or recompile).
Related
Q:
Recently , i face some problems, i have a dll common among a lot of applications,and any change to this dll require to build it, copy and paste it in each bin folder of these applications ,and add the new reference so i decided to convert this dll to a web service in stead to overcome this overload..
I make a web service application contains set of web services(mapping to each class).
I face some problems here:
In the original dll, there are
classes use methods exist in other
classes in the same dll, and i face problems when i
tried to use web service methods in
other web service class.how to fix
this problem.
In the original dll there are set of
static classes with static
methods.how to make the equivalent in
my web service application.
Any overload method cause a problem
in my web service.
When using Dictionary<string, string>
as a parameter in my method.
Note:the original dll contains the connections to the data base. Is converting it to web service is the optimum solution?which one is faster in my case a web service or the dll?Should i tend to WCF instead of?
thanks in advance.
In my applications I usually have all related projects in the same solution. But when I need to use projects across applications I replace the project for a dll reference.
Because I use Subversion I solve the problem of copying the dll by adding an external property do my libs folder, referencing the build of the dll.
If the external dll is updated very often than you probably need a continuous integration system to handle that for you.
I usually add project reference and keep all my projects under single solution, so I do not have file copy issue. You might be missing project reference, instead you could have used assembly reference. Verify that first.
First advice, don't create a web service if you don't know what it is and how it can be used. People tend to think everything is a web service since creating a web service in WCF is so easy by using visual studio tools. Since you ask like converting DLL to a web service, I assume that you are beginning with learning web service.
All you need is kind of continues integration system otherwise a simple build system which does the build for you and it copies the files wherever depended applications folder. Hence you can save your time for coping files manually. When you do this, you will not have any of those 4 problems you have mentioned.
If you are lazy enough to learn the build system, simply write a batch file that would copy the files for you. I do have batch files which does xcopy files.
I have a Web service currently in an ASMX file.
I want to move this code into its own class library project which generates a DLL. I want to be able to drop this DLL into any Web application and have it work.
However, without an ASMX file, I have no URL endpoint. How do I get around this?
Essentially, I want to run a Web service without having to distribute an ASMX. I just want to distribute a DLL. Can I map the endpoint for the Web service in the web.config, or something?
(I think that perhaps WCF might do this, but one look at the config for that, and it feels like the cure is worse than the disease...)
If I understand your question correctly - the short answer is no - you can't turn a web service into a dll.
An .asmx file is essentially a page that has to be served by IIS in order to work.
Although you might experiment with embedding it as a resource and using HttpHandlers to route the request. But in the end that wouldn't really be an asmx service (see this link).
Now, your .dll can CALL a webservice and can have the url configured for the calling of that service in the web.config or app.config whichever you need, but the service itself can't be wrapped up in a dll.
What WCF does is allow you to create a service library, but it still has to be hosted to be publicly available however you can access it as if it were a dll locally by self hosting it.
Here is a sneaky way of getting it that actuall has the app WRITE the webservice if it does not exist - pretty tricky...
Embed ASMX in DLL (sort of)
Would hosting your service in a Windows Service resolve you problem? http://msdn.microsoft.com/en-us/library/Aa529311.aspx
__Allan
I have a fully functional wcf service where I can perform CRUD operations using jQuery on the client. I want this small service application to be portable so I am trying to avoid any app or web.config settings (e.g. Specific address endpoints). I have compiled my service application into a small dll file and have tried it in several different projects hosted at various web addresses. Everything works fine.
The only setting I put in the web.config file was for aspNetCompatibilityEnabled because I am using forms authentication. I did not define a name or a namespace for my service contract and my app.config file is empty sans a connectionstring. When I type in the address to my .svc file I get the 'endpoint not found error'. However my service is fully functional when I use the UriTemplates I defined in my operation contracts. What are the ramifications of this?
I don't care about exposing my data objects or methods on the .svc file. I just need this service to be portable and not blow up due to some unforeseen error.
Cautiously optimistic.
UPDATE
After further investigation it appears my example above is the default behavior for WCF. There is a good article from MS that explains it here.
I'm not sure what do you mean by portable. Your service is in dll, which can be used in any web application. Then it depends on your version of .NET Framework.
In .NET 3.5 you have to host the service in .svc file and configure it (service, endpoints, behaviors, AspNetCompatibility) in configuration file or in code.
In .NET 4.0 you can take advantage of simplyfied configuration model which can create endpoints for you based on other provided information. You can host the service in .svc file, by configuration based activation or by service route. In all cases it is important to use WebServiceHostFactory to allow automatic creation of endpoint using WebHttpBinding. You only need to configure AspNetCompatibility. If you need to futher specify webHttp behavior you can place it also in configuration without specifying behavior's name. Such behavior will be taken as default for all services (also not possible in .NET 3.5).
In neither case you don't need to configure base address because it is always taken from hosting web application.
While consuming a web service in my application I have two choices(ref. msdn)
Adding the Proxy Using the WSDL Tool
2.Adding the Proxy Using a Web Reference in Visual Studio
Now what should I choose, 2nd option is very simple and I generally follow that.
I want to know what are the pros and cons of both the options(if any) and ideally what should I choose?
Thanks.
They essentially achieve the same thing. The second gets the WSDL from the web service and generates the proxy, which requires the service to be online at the time.
Add the reference automaticly when possible, Visual Studio will do everything for you.
Under certain scenarios this is not possible. so you will have to do some manual work, like running the command to generate the proxy class and copying some configuration lines into the web.config manually.
I have a component (an assembly built in .net) that i need to access on (almost) every request to two different websites. One website is written in classic asp and the other one in asp.net mvc.
At the moment i reference the assembly in the asp.net solution and call it like i would any .net assembly. On the classic asp website, i call it through a COM wrapper.
This is all good, except now i need this component to actually stay alive and monitor changes to a configuration file. In my asp.net website i could keep a refence in the application scope and i guess i could register it in component services for the asp access.
Is this the best way to do it? Also, this way the component would actually be hosted twice - one instance in the asp.net application scope and one in the component services. I could perhaps instead only have it live in component services, and then instead reference it from asp.net.
I don't know - something smells fishy (and no, it's not me) - am i on the right track or do you see better alternatives?
Do you really need a long running object? You say you need to monitor configuration file changes -- when the config changes do you need to trigger some actions or do you just need to ensure that each incoming request uses the latest copy of the configuration for your component? If it is the latter then standard .NET configuration should work for you without concern for the object lifetime.
In terms of hosting, do you need to use any COM+ services? If not, then I would not use COM+. If you want one central location for your .NET component, why not register it in the GAC?
Ok so i think i found two solutions, both acceptable for this project:
1) Register it in global.asa on the Application_OnStart in the Application object like this Application("Someobject") = Server.CreateObject("Someobject")
2) Host it in component services and handle lifetime there.