I have a MyComapny.Models project and a MyCompany.DataLayer project. I have about ten services: UserService, PurchaseOrderService, CustomerService, etc.. Each of the services has a reference to both .dlls. When I publish a service, it packages up the referenced .dlls and puts them in my server's IIS XService\bin\referencedDllNameHere.dll. That means that if I want to make a minor change to one of the .dll's, I have to re-publish all ten+ services (or copy the updated .dll in 10 places).
Is there a way to publish the service and have it look at a common location for the two referenced .dlls? This way, there is ONE single location where they would need to be updated. I could simply paste over them and viola. Any suggestions are much appreciated. Thanks.
If you wanted to reference shared copies I would use reflection to load/unload the .dlls at runtime inside your services. This would allow you to reference from a common location and you could change/updated the .dll files without having to rebuild your service code.
Related
I have an .Net webapplication which connects to a reporting web service.
In my development studio, I just add an webreference, then specify the path where the reporting server is installed and reportservice2010.asmx is found and ready for use.
But i do not know how to deal with it, after my application is compiled.
When I would like to distribute it on lets say 100 different servers.
The path to reportservice2010.asmx may(and surely will) change.
Of course what will make my application corrupt.
Please help !
When you added the web reference, Visual Studio should also have added a new section to the application's configuration file. That section specifies the environment-specific details of the web reference.
If, for any given target environment, the target address of the web reference changes then you can simply change the URL in the application's configuration file.
I have an IIS-hosted WCF service, and yesterday I found out there were 66,235 folders (!!!) created in a temp folder 5 levels under the "Temporary ASP.NET Files" directory (\234lkj\98734dc\assembly\tmp). Each one of those folders had exactly one of the dlls needed by the service, which only needs 6, so each dll was copied about 11,000 times on different folders. Does IIS copy them from the bin folder regardless of whether they change or not? Is this normal behaviour? Is there a configuration setting that will prevent IIS (or whatever process is doing it) from unnecessarily copying a dll?
The temp folder is used by .NET to JIT compile references from other services. .NET needs a place to create the files and then compiles this code to eventually work with the service. Now, why you are seeing so many files may have more to do with how the application pool that hosts the site is set up. If you look in the advanced settings for your application pool, look at how many worker processes are assigned. Each worker process can exist with its own memory, so this would require multiple folders being JITed if multiple service references abound. Also, check to make sure that process orphaning is not set to on. If so, your processes can leave behind the files, causing the build up that you see.
Well, the problem is how to organize assemblies for several WCF services hosted in the same domain, when the services might use different versions of the same referenced assemblies?
The thing is, that I have a series of WCF services which are currently hosted in the same domain, but the burden of updating one of these services is overwhelming due to the fact that I cannot be sure not to break other services when doing so. Therefore, it requires that I bring all other services up-to-date with the new version of assembly or assemblies which I am going to publish.
Updating the service - in my case - would be do change one or more assemblies in the bin folder. The problem is that other services might need the same assemblies. I would like to have the possibility of defining subfolders with the name of the service, and in each of these folder have a bin subfolder, the .svc file and all other stuff related to the service. This way I could isolate the service on the same domain.
I have searched for a solution and I have found a blog post by Scott Hanselman about probing, but it seems to apply to .NET 1.1, ASP.NET...
http://www.hanselman.com/blog/PermaLink.aspx?guid=4d0ef4fb-f8ae-4355-a658-3c0432c98dbe
Unfortunately, I cannot make it work for my scenario (.NET 4.0). Furthermore, I am not sure that this would scale the way I need. Even if I could make it work, then is it going to be seperate AppDomains, and if not would that be a problem? I need the complete isolation of the service, but still being hosted in the same domain.
Thanks, Jacob.
Update
Actually, I got a bit further. I tried to put the [ServiceName].svc.cs and the interface into its own project and compile it, and then change the .svc file slightly to reference the assembly just created as described by Hanselman. If I leave out the Import statement also mentioned in his post and doing the other bits aswell, then it actually works.
The only thing is if I have a list of paths, something like...
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="Tasks\bin;Products\bin"/>
</assemblyBinding>
</runtime>
... then can I be sure that the assemblies used are from the right folder, and not resolved in the order they appear in the list? An example could be if the ProductsService uses the same assembly as TaskService but in a different version, then if the assembly is resolved in the order they appear in the privatePath string above then it would use the wrong assembly I guess? Then it is not completely isolated after all.
If I am right in this assumption, then perhaps strong-naming is the answer?
Thanks again, Jacob.
I believe what you need is Service Versioning rather than probing.
You have clients which need to use different versions of the same service over the network. This is a common issue and is addressed by Service Versioning. So they are not referencing DLLs, they connect to the service.
So you just create a new version, deploy to a new endpoint and get new clients using the new service.
I have a WCF service project hosted in IIS. The main SVC file is in the root of the web application folder, and in the bin\ folder are the actual dlls. The web.config (also in the root) contains all the unity mappings. Unfortunately, it seems that because the concrete assemblies etc. are living in the bin\ folder, Unity cannot find them.
Is there a way in the Unity configuration file that one can specify a path (sort of like probing) where the DLLs might live - or to put the path inside the mappings themselves somehow? I don't want to actually have to modify the probing paths in the machine.config etc. if we can avoid that.
I've looked on MSDN and Googled around but couldn't find anything of help.
Any ideas?
I too doubt this is a Unity issue. Have you tried using the Fusion log viewer, FUSLOGVW.EXE, to see what the application is trying to load and where it's looking for the assemblies?
http://www.ademiller.com/blogs/tech/2008/01/gotchas-fusion-log-viewer-your-best-friend-for-assembly-load-errors/
This should tell you what the current probing path looks like and you can take it from there.
This wasn't a Unity issue in the end - it was more that I was trying to host the application within IIS and had to configure that correctly.
thanks for any assistance.
I'm creating a wcf web service for an external client.
The client is requesting a copy of the wsdl.
I currently am waiting on being able to provide the client with access to the service.
when I go to my local webserver running the service (http://localhost/Services.svc?wsdl) I am shown
the wsdl, the data provided contains the method signatures (from the .svc code behind),
but does not contain the included model objects (Customer, Order, ext).
To get those objects, I can find the references in the shown data and go to the url
For me to provide all needed information to the client, so that they have the entire wsdl
should I provide the main schema and also each of the imported schemas?
or is there any other way of accomplishing this (other then the client hitting a server)
ie: is there a way of packaging all of them within one file?
(Seems like something would be available to extract each of those files?)
If I were to give a .zip with each of the files, would that be enough?
Thanks,
Steven
WCF packages up its WSDL and XSD (XML schema to describe the data being sent around) into various pieces, as you've already noticed. Those are referenced from your main WSDL with additional href's.
Or even better: you can run the "svcutil -metadata" command on the command line against the DLL or EXE which contains your service implementation - this will create all the needed files (typically several WSDl and several XSD) in the directory where you run the svcutil command. That's usually a more reliable way than piecing together the WSDL and XSD files from the ?wsdl URL (you usually end up missing one or two files).
Marc
If you manually downloaded each and every sub-WSDL and XSD referenced, then yeah, it would work; but it's cumbersome, to say the least.
An option worth looking into would be to use Christian Weyer's WCF extensions for flattening your WSDL so that WCF generates everything in a single file, then giving that to your client.