I have a WCF visual studio project, which contains many SVC files.
Can I compile each SVC file into its own dll file?
my target is to be able to deploy each svc file separately without touching other services, but maybe keep them on the same website
what options I have?
No, you cannot compile the svc files.
You can however compile your actual service code into an assembly (if you haven't stuck it into YourFile.svc.cs codebehind file), and then deploy that compiled assembly into the bin directory below the virtual directory where you svc files exist.
If you want to have an assembly for each service, you will need to create a class library project for each service, put the service implementation inside that, compile it, and then deploy that resulting assembly into the bin directory.
The svc files must be deployed as is, and they must be copied into a virtual directory (or a subdirectory thereof) in IIS.
Related
I have a .NET windows service made in VB.NET in Visual Studio 2013. In this project I have some DLLs referenced and also in app.config I have others defined as dependentAssembly (I didn't make this project).
When I compile this project, dependent assemblies specified in app.config are not being copied to output directory (debug or release depending on the case).
My questions are:
What is the difference between specifying dependent assemblies in app.config and reference a DLL?
Why dependent assemblies specified in app.config are not being copied to the output directory (debug or release) when compiling?
Can I force visual studio to copy dependent assemblies specified in app.config to outut directory (debug/release) when compiling?
Here is the relevant information I found about dependentAssembly. App.config should not be used on dlls, but only with executables.
If a dll is loaded in an executable, the dll will use the configuration file of the running executable and will ignore the configuration defined for him.
If you like, you can read the configured keys using some ugly code that takes them from the configuration file for the current assembly.
What you should do is put the relevant configuration into the exe configuration file. You can checked in this link for more details.
I have WCF Service Library project and have configured slow cheetah extension for transforming .config files.
When I run publish on the project the build output produce in bin folder appropriate dll file for the service and NameOfService.dll.config file which is transformed correctly.
The publish process also produce .svc and web.config file. The issue is that the web.config file is not transformed.
Is it possible to get also web.config file transformed by this process and how ?
IIS WCF web services refer to the .dll in the BIN folder. What configures this location?
Though I've never had a reason to change it myself, I believe it can be done from the system.web section of your configuration file (CodeSubDirectories property):
http://msdn.microsoft.com/en-us/library/system.web.configuration.compilationsection.aspx
I am having a problem with the log4net file in a WCF service i have created.
When i build and run my WCF services it created log4net then errors with the following...
"Could not load file or assembly 'log4net' or one of its dependencies. An attempt was made to load a program with an incorrect format."
When I delete the fle from the bin folder and refresh the browser the services run fine.
So, how can i stop the log4net being created in the bin foler when i build my project? as i dont need it
Somewhere in your service project, you probably have a reference to a log4net assemly. Or the log4net assembly is referenced in another assemly that is referenced in your service project. Somehow it is chained-in as a dependency for your service to be deployed and is therefore copied into your bin folder.
Find the reference to the log4net assembly, select it and select Properties from its context menu. In the Properties window set Copy Local to false. This will prevent the assembly to be copied into the output bin folder.
I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!