I have had to make changes to an assembly reference for a project that runs as a service.
Since then I have had trouble getting the thing to run. It seems that somewhere along the execution of this thing it fails and stops the service.
The .dll in question has been deployed to other projects that run as a scheduled task and hasn't caused any issues there.
This post here (stackoverflow services) suggests that all I need to do is stop the service and start it up again having swapped out the dlls, but I get the feeling I am missing something?
Or even better is there a way to see if the executable that the service runs is working, like in task manager?
EDIT:
I can see what is breaking it and it's entityframe work throwing an exception relating to MetaData, I have a "Core" and and "Application" layer to this project, the core handles the data and the EF models, but it seems the metadata between the connection strings is different eg:
metadata=res://*/EntityFramework.AutomaticOrderingEntities.csdl|res://*/EntityFramework.AutomaticOrderingEntities.ssdl|res://*/EntityFramework.AutomaticOrderingEntities.msl;
which is different to the below:
metadata=res://*/EntityFramework.WebstoreEntities.csdl|res://*/EntityFramework.WebstoreEntities.ssdl|res://*/EntityFramework.WebstoreEntities.msl;
They are both the same name and catalog etc in the connection strings, do they have to be the same?
Related
I have to work on already developed solution which is using NHibernate (v1.2.1.4000) with SQL Server 2008.
The application is using .NET Framework 2.0 due to Membership authentication and other stuffs.
This is working in Visual Studio - I can debug it, run in. But failed when deployed in IIS (v8.0)
Exception is:
Duplicate type name within an assembly.
HibernateException: Creating a proxy instance failed.
And it occurred whenever database is fetched to get some models.
I have googled on this issue and have some suggestion to use nhiberante (v3.3.x).
But the lots of interfaces and method parameters are different in v3. so it is breaking implementaion of the source code.
Several questions regarding this exist on stackoverflow but no luck yet
Maybe you have a concurrency trouble, something like singleton initialization failing to ensure uniqueness of its initialization, occurring only under load.
Especially check your session factory. Put logs when building it, check it is not built multiple times. Try triggering your singleton initializations from Application_Start if they are not already triggered from there.
Avoid singleton lazy initializations unless they are really heavy and not needed for most of you application HTTP requests. In such case, make sure their logic is thread safe and avoid running concurrent initializations (something like LazyThreadSafetyMode ExecutionAndPublication instead of PublicationOnly: it requires stricter locking but must be done that way for building the ISessionFactory, if it is done through lazy initialization.)
I am having a bit of a terrible time getting a WebAPI 2 setup to work. I am trying to place this within an already existing solution containing multiple projects.
The current layout is (with generalized names):
-Server.Project
-Services.Project
Right now, IIS is doing the hosting. There is an application setup in IIS called Application.
So, right now if you go to localhost/Application/service.asmx , everything spins up and does it's thing. The global.asax.cs file and most of the service classes are in Services.Project, even though Server.Project is the software's entry point.
I want to make use of WebAPI's new things.
I've defined a controller (TestAPIController) in Services.Project, and a configuration file with the default mappings (from all of the examples). The Register() function is called from Application_Start(). I've verified that it is at least being called.
If I go to:
localhost/Application/TestAPI/anything ever, it gives me a 404 error.
I tried to use the Route Debugger by installing the package and going to localhost/Application/rd (also tried /Application/TestAPI/rd). Neither work. I get a 404.
This leads me to believe I have something setup wrong so that the WebAPI stuff is not actually spinning up and hosting correctly.
I have tried doing the OWIN startup as well, but it didn't seem to help.
For that, I just added the appropriate startup class stuff to my web.config, and to my Global class in Services.Project.
I've verified that the Configuration() function for Owin is being called as well, but I still cannot hit the paths I've setup.
I think the fact that the entry point is Server.Project, but the controller/routes are defined in Services.Project might be part of the issue.
However, all of the assemblies are placed in the same bin directory. I was lead to believe this should allow everything to be loaded/found.
Am I missing something?
If anything is not clear, sorry. Let me know so I can clear it up.
Thanks.
EDIT:
So, I got a different route debugger to install and cooperate.
(install-package RouteDebugger).
If I hit my main URL: localhost/application
This route debugger launches and shows that no paths were matched, but it ALSO shows the routing paths that I defined but are not found.
...so now I am even more confused. How are they showing up and obviously known about, but are unable to be reached?
If you followed "typical" WebAPI setup tutorials, you would have defined the custom ApiController route to include "/api".
All of your urls should look like:
localhost/Application/api/TestAPI/anything
As an aside, it might be worth it to just spin up a brand new Web API project. Retrofitting an existing project might cause more headaches than it's worth.
We're working on an EF6 application, that uses a custom DbConfiguration class. Up til now, we've been configuring system to use our DbConfiguration, rather than creating a default, by decorating each DbContext class with a DbConfigurationTypeAttribute.
We installed an instance on our QA site, today, and were getting HTTP 500 errors. After turning off CustomErrors, so we could see the detail, we saw:
An instance of 'DbConfigurator' must be set at application start
before using any Entity Framework features or must be registered in
the application's config file.
This confused me, because according to Microsoft, the DbConfigurationTypeAttributes should have worked:
https://msdn.microsoft.com/en-us/data/jj680699#Moving
And they did work, on our Development machines. And I am absolutely certain that each of our DbContext objects is so decorated.
Not knowing what else to do, I added the codeConfigurationType attribute to the entityFramework element in the web.config and everything ran fine.
I then tried removing the DbConfigurationTypeAttributes from the code, thinking that defining this in multiple places was a bad idea. And all my unit tests proceeded to fail - they don't access the web.config. That part, at least, makes sense.
The rest of it, though, confuses me. Why do the DbConfigurationTypeAttributes not work, when running in IIS7?
I am writing a Web Service in C# and am an outright novice. Please pardon me if what I have asked is dead silly. I have a set of dlls that the Web Service uses. What I want to achieve is as follows:
Let us assume that the dlls are first.dll, second.dll and common.dll
common.dll is referenced in first.dll and second.dll (common.dll contains interfaces that are implemented in first.dll and second.dll)
common.dll has a static dictionary of the types of classes contained in first.dll and second.dll. Classes from this dictionary are instantiated as required.
Whenever I have a new common.dll ready for release, I want to manually delete the common.dll file and replace it with the new release of common.dll while the system is live/running.
Presently, I am getting the following error when I am attempting to perform step 4:
"This action can't be completed because the file is open in vshost32-clr2.exe"
It is so that I am missing something completely?
24/7 availability is not a cheap thing - do you really need one?
One of easy approaches is to re-route traffic to different servers when you upgraded your application. You get both servers running and verified that new one is OK and than switch traffic to go to new one. You can use DNS entries or some software/hardware router to redirect traffic.
If you really want to replace assemblies on the fly you can do that. You may need enough layers of proxy objects and potentially load your final assemblies in custom app-domain. You may be able to get away with simply copying DLL to root folder of Web Site on IIS and hope that app-domain recycle will work correctly and satisfy your "always live" requirement.
Note: "manually delete" and "the system is live/running all the time" should not appear together for the same system... unless you know of a person who can flawlessly perform the same boring tens of steps multiple times at any time of day...
You have to shut down the hosting website. Copy in the new assembly. Then restart the website.
I am using VSTS2008 + C# + .Net 3.5 to develop a WCF service hosted in IIS 7.0/6.0. I am learning from the following MSDN link,
http://msdn.microsoft.com/en-us/library/ms733766.aspx
My question is, suppose I implement the WCF service inside a class library and compiled into some specific DLL assembly. In the service svc file, seems there is no way to specify the assembly, in the MSDN sample, only full (including namespace) class name is specified. So, how did WCF runtime finds the assembly which contains the actual implementation of the DLL assembly at server side? Even if I put the assembly into bin sub-folder of the virtual directory, and if there are many DLLs in bin sub-directory, how did WCF runtime knows which dll contains the actual implementation for the specific WCF service?
Marc is correct about putting the assembly name after the namespace with a comma to separate it: I can confirm that it worked for my own WCF service when I did that. The "dll" extension was not required.
So it sounds like your error 404.3 is due to something other than that. I'm sure I've had that one before, though I'm unable to reproduce it when I try to now. But I have a feeling it had something to do with the permissions on the folder in IIS - perhaps check to see if opening up the permissions more will fix the problem. I think the relevant users would be the IIS_IUSRS on your own machine, and maybe also other processes like NETWORK SERVICE (though I could be wrong on this).
The other thing that springs to mind is encryption; I found that when my web folders were encrypted (with the standard Vista encryption) they couldn't be accessed properly by IIS and would give errors like this. So if you have encryption on those files/folders, maybe try turning it off.
(not working - I've left this here simply for visibility so other SO users can see what didn't work)
I'd need to check, but I'm fairly certain it follows the usual pattern - so you could also have written "Some.Namespace.Service, Some.Assembly.dll" (or if that fails, try it omitting the .dll from the end).
I seem to recall that there is one minor change to normal here... usually the runtime will respect [assembly:TypeForwardedTo(...)], but I don't think that WCF handles this - but otherwise, standard type/dll strings should work.