I am getting an annoying build warning in my web config. I have about 40 warnings of Global element '{element name}' has already been declared for all the elements in my web config. This is for a WCF service I am creating in the same solution as an MVC website. I suspect that the issue is that the WCF service references the MVC assembly (to reflect some metadata), and both web config files are somehow being included resulting in duplicate items. Searching has only turned up different issues than the one I am having.
Is there any way to fix this issue, perhaps by telling the configuration manager to ignore the config file in the referenced MVC assembly?
EDIT: While trying to separate my different dependencies as much as possible, my warning messages went away after shutting down the computer.
Separate your service from your host. IE have your service in a more or less pure assembly and then reference that from your console host, your wcf host, your windows service host and your mvc host projects separately.
Related
I am getting build failure due to warning in my web.config. Everything was fine before I added .net 2.0 Web service reference to the MVC project. I got warnings of Global element '{element name}' has already been declared for all the elements in my web.config. Searching has only turned up different issues than the one I am having.
Is there any way to fix this issue, perhaps by telling the configuration manager to ignore the config file in the referenced WS assembly?
I can not use the regular service reference as I am not able to call it via https. Or is there a way to reference the 2.0 web service as the regular service reference that can be invoked via https/ssl connection?
Edit: I also have a WCF service reference declared in the project, will that complicate the matter?
I figured out. I don't have to add .net 2.0 WS reference to the project. I can use in web.config to specify the transport protocol to be https.
However, it is wired that adding a web reference would invalidate the web.config elements. I would like to learn the cause of that and would appreciate your input.
I made a great WCF service in my dev environment, then when I pushed it up to production I got various errors saying "This collection already contains an address with scheme http..."
So, I created a Custom ServiceHostFactory class for my service.
Now when I upload it I get:
The CLR Type 'WCFServices.MultipleHostFactory' could not be loaded during
service compilation. Verify that this type is either defined in a source
file located in the application's \App_Code directory, contained in a
compiled assembly located in the application's \bin directory, or present in
an assembly installed in the Global Assembly Cache. Note that the type name
is case-sensitive and that the directories such as \App_Code and \bin must
be located in the application's root directory and cannot be nested in
subdirectories.
I checked the GAC and my assembly is indeed there.
Can anyone explain why this error is occuring?
Again, I am using .NET 3.5 on Sharepoint 2010
Is it "WCFServices.MultipleHostFactory" or "WCFServices.MultipleHostsFactory"? If its the first, thats why because that namespace does not match that you said in your question.
It turns out that I was able to remove one of the bindings from the application host configuration file. After talking with the administrator, I found that he had two bindings for port 80. One was IP:80:[DNS name] and the other was :80:
We agreed to get rid of the :80: binding and the WCF service was able to deploy to SP.
If anyone ever runs into that CLR loading issue, please post with a solution. I still don't have a good explanation for that problem.
I have a C# WinForms Project which contains some WCF service definition files which I have created in the project by adding standard classes (not using Add Item > WCF Service).
The project contains some dependencies that require me to build the project for x86 processors.
If I edit the app.config file with the WCF Service Configuration Editor and try to use the "Create New Service ..." wizard, and then browse to the project EXE file (in the debug folder) I get an error, (which I've read is because I'm targeting the x86 processor):
Could not load file or assembly 'EXE_FILE_NAME' or one of its dependencies. An attempt was made to load a program with an incorrect format.
So, upon changing the target to All CPUs, compiling the project again, and then trying to create the service in the WCF Service Configuration Editor again, I now get a different error:
Could not load file or assembly 'SOLUTION_NAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
(To clarify, I CAN still compile the project when targeting all CPUs, but get an error at runtime due to a dependency)
Is anybody able to help me with this problem, so I can add the services defined in app.config file using the wizards in WCF Service Configuration Editor? (I think that if I add the services to the WCF Service Configuration Editor when targeting All CPUs I can make any modifications thereafter, regardless of the target)
When debugging, look at the exception detail. From what you've described my guess is you will an assembly loading error in the fusion log because the dependencies of the WCF service can't be satisfied by looking in the default locations.
Say for example you're referencing MrCritter.MyService.dll which defines a WCF service and has a dependency on something like log4net or nHibernate. As long as nothing from those dependencies is leaking into the WCF host (eg returning an ILog) yes you'll be able to compile fine but will get ReflectionTypeLoadException thrown when trying to instantiate the service class if those dependencies aren't somewhere it can find (eg in the executing directory, in GAC etc).
I tried to use separate assemblies for the implementation, contract and WCF service library but starting the service in debug produced an error because it couldn't find the service/contract. If I move them into the same assembly it works. What is needed to wire up the WCF when it's in different assemblies?
Shouldn't be anything special to do - we've got hundreds of services running with contracts and impls in separate assemblies, and it works just fine. Are you self-hosting with ServiceHost or using IIS? If you're using IIS, make sure the host project has references to both assemblies so they all show up in the bin directory together. You may need to at least partially assembly-qualify the type name in the ServiceHost directive's Service attribute (ie, MyImplNamespace.MyImplTypeName,MyAssemblyName).
I have three projects in my solution:
A WCF web service which provides functionality I want to test
A Web Application which calls that web service
A test project which runs tests on the service.
The web service and the web application both use log4net with separate configuration files and this line in the AssemblyInfo.cs for configuration:
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config", Watch = true)]
When I browse to the URL of the web service (http://localhost/MyWebService/MyWebService.svc), It appears as expected - information and a link to the wsdl.
When I use the web application, it all works correctly. The code calls the web service and gets correct responses in reply. Logging occurs from both the web app and the web service.
However, when I run my unit tests, they all fail with the following exception:
Test method MyServiceTest.MyServiceAuthTest.TestValidateCorrectly threw exception: System.ServiceModel.ServiceActivationException: The requested service, 'http://localhost/MyWebService/MyWebService.svc' could not be activated. See the server's diagnostic trace logs for more information.
In the Event logs for my local machine, I get the following message:
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/12905972
Exception: System.ServiceModel.ServiceActivationException: The service '/MyWebService/MyWebService.svc' cannot be activated due to an exception during compilation. The exception message is: Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045).
I've removed and replaced the references, cleaned and rebuilt, and even purged the temporary asp.net files, all to no avail. The web site calls the service with no problems, but the tests fail.
Does anyone know what could be happening here?
Update: I removed all references to log4net and the tests ran and succeeded without a problem. Obviously, this is far from preferable. Any suggestions?
Update 2: Some combination of these two things fixed the problem:
Added a reference to log4net in my test project, making sure to initialise it completely.
Used the release build of log4net 1.2.10 rather than the debug build.
Do you have a reference from your unit test to the log4net library? Try it out.
The reason behind this: Most unit testing frameworks are shadowing the binaries to somewhere else during the test run, but by doing this they do not find deeply nested references in all cases. I once met this with NHibernate and log4net. In case of MSTest you cannot deactivate shadowing. NUnit GUI has an option for this, but I don't have it installed, so you have to look for it on your own :-)
I would also consider to add log4net handling into your unit tests configuration. This is very helpful when looking at failures anyway.
This link explains it for NUNit and it should be possible for other frameworks as well.