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.
Related
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.
I have an WCF RESTFull Service which i need to deploy on IIS6. I have never done this before and i am completely new to the IIS environment. I found a good solution here on the forums but its not precise enough for my case. maybe someone can give me based on this solution a more expanded version:
Option 1 - "bin" deploy (preferred option)
compile your WCF service into a DLL (class library)
create a website in IIS6
copy the WCF DLL's into the website's .\bin folder
create a *.svc file in that website
add an appropriate web.config in the website folder to define your endpoints and service configuration etc.
Your WCF service will now be reachable at the website's base address, plus the name of the *.svc file, e.g.
http://myserver/someweb/Myservice.svc
Your *.svc would look something like this:
The Service= attributes denotes the class implementing the service - fully qualified with its namespace.
What is the .\bin folder in point 3. ? Where can I find it?
I need the exact settings for the property page tabs of the website please. Also the address: http://myserver/someweb/Myservice.svc ... What is the someweb ? the physical directory of the website? or the base address from the webconfig file?
An exact step for step guide with all needed settings would be great.
For the '/bin', manually create it in the root of the website you create and copy the assemblies into it.
Create the .svc in the root of the website and access it using a similiar url to;
http://yourwebsitename/service.svc
I have a wcf service application that has some application startup code in the app_code folder of the project. When i publish this project to my website, it deploys it with source code and app_code folder.
Is there a way to precompile the wcf app ( like an asp.net app), that includes all the dependencies and compiled code ?
i checked the web deployment package files, and even that has the source code of app_code folder.
problem here really is that since the template for wcf does not expect app_code folder and .cs files in it, they get added as content, changing them to compile would include them in the web dll
Your best bet would be to:
put all your WCF service-related code into a separate class library assembly
deploy that assembly to the .\bin directory
only put your MyService.svc file (without any code-behind) to your virtual directory
With this setup, the WCF service is still being hosted by IIS, but you don't need to do any special tricks and hacks to get it to work properly.
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.
I have a Windows application in .Net 2.0 that uses several levels of configuration files. For reasons out of my control, the application consists of a Windows app (.exe) project and several DLLs, each of which has its own app.config file.
I have successfully figured out how to read the config file for each DLL, using (in C#)
ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None);
This works just fine - I can confirm that I get a Configuration object from this method when pointed to the file path name of my DLL's configuration file ("foo.dll.config"). However, when I try to access a custom configuration section, I get an exception saying that the data type for my custom configuration section cannot be found.
What else do I need to do to get the typing information available to my code when loading a configuration file in this manner?
It's unfortunate but true: the way to handle this is to copy the configuration from the .dll.config files into the applications' config file. The only exception has something to do with the Settings system used in Windows Forms. I think that does the OpenMappedConfiguration for you, but I'm not sure.
I've never known why they didn't unify this in .NET 2.0 and solve the problem. Maybe I should ask.
Earlier in the day, I asked a question like this as relates to WCF, in the Oslo Forum on MSDN (http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044-b1f0-43ad72fb508d). As I was searching for a blog post or some other answer (as I said above, "maybe I should ask"), the answer to my Forum post arrived.
Long story short, and somewhat tongue-in-cheek, the answer is: they didn't fix this in .NET 2.0 because they were waiting for Oslo to solve the problem.
Without trying to avoid downvotes by making sense out of that, I'll just mention: Oslo will encourage models of applications and application components to be stored in a central repository. That will include models of per-instance configuration. The theory is that all such data would be stored in a single repository (at least per-system). So, no more question of where the configuration file is located it's all in one place. No more question of finding the assembly containing the configuration section metadata - the metadata is stored in the repository along with the configuration data.
Ask me tomorrow, and I may feel differently, but right now, I may be picking up the Oslo religion...