I have a WCF service which references a 3rd party DLL. That DLL looks for a settings file in the same directory as the DLL. However, WCF by default sets the current directory to "Inetpub" so of course the setting file can't be found.
I tried to set WCF to "Aspnet compatibility mode" but that didn't seem to work.
Any help is much appreciated!
Can you pass in the location of the settings files to the DLL? That's when the Aspnet compatibility mode comes to use, see this answer.
But this might be what you're looking for.
Maybe you can try to access it from System.AppDomain.CurrentDomain.BaseDirectory.
Related
I'm relatively new to WCF so please forgive the rookie question. What I'm struggling with is trying to get my WCF service to remember its configuration at the service level. I'm happy that I've modified my Web.Config within my WCF project correctly, but now I want to modify the Client.dll.config and have it save. I am able to edit it happily, either by following the path directly to the file or by using the tool, but it never retains the settings. Why??
Thanks in advance
Ian
Perhaps when you recompile the client solution, the Client.dll.config file is reset. Try to update the App.config file in your client solution.
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 wcf client. It uses .NET 3.5.
When I compile the client I get two files:
client.exe and
client.exe.config.
The second file contains configuration for the wcf client.
In my case I need to prevent the user sitting on the computer to see the urls and change some other parameters from the config file.
So the requirements are, the end user not to see and modify the data stored in the config. The config file contains the same data as app.config. I need to forbid the person using the program to see the end point urls so easy.
Also I have a lot of configuration there so I do not like to code in the moment.
Is there any solution for the problem (embedded app.config of something else)?
Edit: I do not need configurable options. The config file is automatically created when adding service reference from the studio.
Regards
You can also create your proxies programatically instead of using the service reference feature.
Every parameter in the serviceModel config section can be represented in code as well.
The ChannelFactory class will help you create proxies to the service.
You can easily encrypt entire parts of your config files - and not just web.config in web scenarios, but also application config's in stand-alone apps.
Check out some resources on how to do this:
Encrypting web.config values
Encrypting passwords in .NET app.config file
Encrypting the app.config file for Winforms application
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.
I'm throwing together a quick data service in WCF to be accessed by a public Silverlight 2.0 application. As my data is very static and relatively simple I'd like to just store it in local XML files (which is made easier as there are a VERY limited number of people who will ever edit it).
I'm wondering what the best way to find a relative path from within my service will be. In traditional ASP.NET I could use the Server.MapPath....within this WCF service nothing similar is available. This solution will ultimately be hosted at a hosting provider I have no control over so I can't hardcode any fixed locations. I'd much rather just get a relative path to some XML files in my AppData folder.
Any suggestions?
You could try using Environment.CurrentDirectory or AppDomain.CurrentDomain.BaseDirectory
Try using HostingEnvironment.ApplicationPhysicalPath.
The WCF services still have access to a lot of the same things as your ASP.NET pages (since, in the end there is still an HTTP request and response). You can still use Server.MapPath like so:
HttpContext.Current.Server.MapPath(...)
You could store the files in IsolatedStorage instead of in your folder for the application. Look at the example on the linked page to see how it works.
First, add an operation to the service to return the current directory. Have the new operation just return Environment.CurrentDirectory. In the client, check to see if you are surprised by what the current directory was. Adjust as needed.