I have several web applications that make use of packages using WebActivator. On my local machine with IIS 7.5 Express, everything works fine whether I test in Release or Debug configurations. However, on my production machine with IIS 7.5, WebActivator doesn't actually run, so all the modules fail to load and I have to add the code back into the Global.asax.cs file.
I'm stumped as to where to even begin looking - Googled and searched StackOverflow but haven't ran into anyone having similar issues. Is there anything explicit that needs to be configured to allow it to run?
Edit - Added quick sample of activator that logs to Windows. The function contents, when added to the Global.asax.cs file runs fine on the production server, but never logs from the activator.
using System.Web.Mvc;
using System;
[assembly: WebActivator.PreApplicationStartMethod(typeof(Admin.App_Start.WebActivatorTestStart), "Start")]
namespace Admin.App_Start
{
public static class WebActivatorTestStart {
public static void Start() {
System.Diagnostics.EventLog log = new System.Diagnostics.EventLog();
log.Source = ".NET Runtime";
log.WriteEntry("WebActivator Start", System.Diagnostics.EventLogEntryType.Information);
}
}
}
Well, I can't say for sure what I did to fix things, but it's working now.
A bit of history - I manage a number different large applications all using some common libraries. I have my common web library and that's where I used to have the IOC setup with Ninject and WebActivator. This base library had the App_Start folder in it. Maybe this was the reason? Dunno. Never got WebActivator to work with this setup so I just used the NinjectHttpApplication to handle registration and startup stuff. However, the base library still had a dependency on WebActivator (just no App_Start folder).
So now I'm working on refactoring some of the applications and the base libraries - clean up a bunch of code smell from the past few months. One step was to move all the IoC up to the actual web application - make the base libraries less monolithic. The base library no longer has any dependency on WebActivator.
And now it works. There also half a hundred other small changes I've made to the base library, so I apologize to others for not being more systematic about it.
Related
I have an old asp.net that I'd like to move from a Windows environment to Linux.
The application has an old Web.config, a bunch of dlls and an App_code folder.
Can you point me in the right direction to getting this working?
What I've tried so far:
dotnet publish -c Release -o /var/www/blah
But this complains:
app_code/Rewriter.cs(3,14): error CS0234: The type or namespace name 'Web' does not exist in the namespace 'System' (are you missing an assembly reference?
I read that System.Web doesn't really exist anymore.
My question is, can I reference some kind of build environment that will build and deploy this old-style application? Or so I need to port all the code?
Migrate any business logic to classes, so you can reuse it. The more code you can move to classes (or even class libraries), the easier it will be. Then create a new ASP.NET core application and rebuild the UI bits.
The hardest part is if you have a lot of spaghetti because you over-utilized the event methods in your code behind files. You may end up with a lot of refactoring, but the idea is to keep it working as is, but with the actual code outside of the ASPX pages. Once your event handlers look more like this
public void THisButton_Click(e as EventArgs)
{
OtherClass.Method();
}
you will find it much easier to migrate to MVC, which is how you will want to design the UI with for ASP.NET Core.
If this is not making sense, let me know, and I can see if I can point you to some information that helps.
I really tried hard to find a similar issue to get some leads, but no one seems to describe the case we are having, so here it goes.
Background
We have a product with the following general design:
[Local installation folder]
Contains a set of .NET assemblies, implementing the bulk of our product functionality.
Example: Implementation1.dll, Implementation2.dll
[GAC]
ClientAPI.dll. Our client assembly, to be referenced from end user Visual Studio projects. Has strong references to the implementation dll's in the local installation folder.
In ClientAPI.dll, we have an entrypoint we require end user projects to invoke. Lets call it Initialize().
The very first thing we do in Initialize is to install a so called assembly resolve handler on the current domain, using the AssemblyResolve event. This handler will know how to locate the implementation dll's and load them into the client process, using Assembly.Load().
Consider a console application. It will look something like:
class Class1
{
void Main(string[] args)
{
ClientAPI.Initialize();
// Use other API's in the assembly, possibly internally referencing the
// implementation classes, that now will be resolved by our assembly
// resolve handler.
}
}
Now, all is good in the console/windows forms/WPF world. Our assembly resolve handler is properly installed and invoked, and it can successfully resolve references to the implementation DLL's once ClientAPI.dll require their functionality.
Problem statement
With that being said, we intend not to support only console or WPF applications, so we were relying on the same design in ASP.NET. Hence, creating a new ASP.NET Web Application project in VS 2010, we figured everything would be as straightforward as:
class Globals : HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
ClientAPI.Initialize();
// ...
}
}
A few 20-30 hours of dwelling in the ASP.NET runtime universe, trying the above in both the development server and in IIS, we've learned that things there are not really as we expected.
It turns out that in ASP.NET, as soon as the ClientAPI class is referenced anywhere, all references it has to any other assemblies are instantly resolved. And not only that: the results are cached (by design, since .NET 2.0 we've found), meaning we never have a chance at all trying to assist the CLR.
Without further elaboration about the different things we've tried and learned, it basically comes down to this question we have:
Why is ASP.NET resolving references like this? It is not compatible with how other types of applications does it, and even more, it is not according to the documentation of .NET / the CLR runtime, specifying that references to external types / assemblies are to be resolve when first needed (i.e when first used in code).
Any kind of insight/ideas would be highly appreciated!
Windows Forms / WPF applications run on individual client machines (and therefore run in a single, local context), whereas ASP.Net runs within IIS, within an application pool, on a server or set of servers (in a web farm situation). Whatever is loaded in to the application pool is available to the entire application (and therefore is shared between all clients who connect to the application).
HttpApplication.Application_Start is executed once, when the application starts up. It is not executed per client as it would be with a Winforms application - if you need to initialize something for every client that connects, use Session_Start or Session_OnStart, but then you may run in to memory issues with the server, depending on how many clients are going to connect to your web application. This also depends on whether your class is a singleton, and if the Initialize() method is static. If you have either of those situations, you're going to run in to cross-threading problems fairly quickly.
Additionally, it's worth noting that an idle IIS application pool will reset itself after a period of time. If no one uses the web application overnight, for example, IIS will flush the application's application pool and free up memory. These settings can be changed within IIS administration, but you should be careful when doing so - changing these settings to circumvent a badly designed object (or an object that isn't designed for a web application) can create even more problems.
FYI - I'm being a little fussy, but for the avoidance of doubt, the object is not cached - yes, it is loaded in to memory, but how the memory is managed is up to how you've designed the object (caching in the web world is an entirely different thing, and can be implemented in many different layers of your application).
Don't try and make a web application act like a windows application; you'll just create yourself more problems!
I've upgraded MVC3 from RC2 to RTM. We were using Ninject 2.1.0.76, but things stopped working once I upgraded. So I used the NuGet manager to get the latest Ninject, Ninject.MVC3 and Ninject.Web.Mvc libraries (2.1.0.91, 1.0.0.0 and 2.1.0.39 respectively). Now, it creates an AppStart_NinjectMVC3 file.
I removed NinjectHttpApplication from my global.asax and made it back into a regular HttpApplication. When I tried to build, I get;
"Exception has been thrown by the target of an invocation"
Looking further, if I disable the following line;
DependencyResolver.SetResolver(new NinjectServiceLocator(kernel));
The build goes through. But I'm pretty sure I don't want to do this.
Any ideas?
----- UPDATE ---------
I created a new MVC3 project, added the reference to Ninject.MVC3 and this builds and runs fine. I compared web.config, don't see any differences that relate to Ninject or MVC in the two. A fresh project doesn't add the Ninject.Web.Mvc library, so I removed it and commented out all code relating to that, and still, the error occurs.
Since ASP.NET MVC 3 Beta the IServiceLocator interface is replaced by IDependencyResolver. I'm not sure Ninject.MVC3 already has a release where they have implemented this interface.
Judging from the line DependencyResolver.SetResolver(new NinjectServiceLocator(kernel)) it appears they have not.
Here's a simple implementation of this interface for Ninject.
UPDATE: The Ninject.Web.Mvc library has a NinjectDependencyResolver class that extends from the IDependencyResolver interface. I think you should use this one (I do and everything works fine).
Download the dlls from here
https://github.com/ninject/ninject/archives/master
https://github.com/ninject/ninject.web.mvc/archives/master
Further more do not use Ninject.MVC3 all you need ist Ninject.Web.Mvc
I also have an article documenting same here
I have a Web service which, when updated on one computer with VS2008 works perfectly fine, but on another computer does not. The critical difference is the contents of the auto-generated Reference.cs.
In the correctly functioning environment, the methods have fully qualified class names, refering to classes in a class library. However, in the problem environment, the class names are unqualified and partial classes are declared near the end of the file. E.g.
public string MyMethod(MyClass pr_Class)
...
public partial class MyClass {
}
versus
public string MyMethod(Class.Library.Namespace.MyClass pr_Class)
This causes errors such as:
'<ClassType>' is an ambiguous reference between <ClassLibraryNamespace>.ClassType and <WebReferenceNamespace>.ClassType
The code is under source control. Checking out to the working environment works straight away, checking out to the problem environment will only work if the reference.cs is manually edited to be like the working environments. Transferring the project manually from problem environment to the working one only requires an "Update Web Reference" to be performed to allow compilation. Both Reference.cs files claim to be auto-generated by the same tool version. The settings from the good environment have been exported to the other. No success so far...
Any ideas would be greatly appreciated!
Matt
Ok, so I have the answer. The working environment has a long forgotten extension library for importing web references. Customizing generated Web Service proxies explains the procedure. I'm new to the project and so had no idea about this!
I've a simple, if not primitive, C++/CLI .NET 2.0 class library. It is used in order to wrap some C++ legacy code for the Web Service. The following facts appear to be true:
Primitive C# test program calls class library and it works.
If class library does not refer to any modules of our code base, it works as well as part of the web service. That is, I load the web service and invoke the methods and receive proper response.
The same moment I replace the copied and pasted code by the calls from our code base libraries, the Web Service stops to load. I get System.IO.FileNotFoundException message.
The problem: I cannot find any place where the file name that couldn't be found is written.
I googled it and gave some permissions to some ASP.NET user on my computer. I copied all the DLLs of our libraries into the same directory where web service is installed. I searched in IIS logs, event logs, etc - no where could I find the name of the module that prevents the web service from coming up.
Any help on the matter would be greatly appreciated.
Boris
Make sure all the dependent DLLs are in the path (Path meaning not the directory where your assembly is, because ASP.net copies your assembly away into a temporary folder, but rather a directory that's included in the System path environment variable).
What calls are you replacing? Could it be the original code gracefully handles missing files (which may not even be important) and yours does not?
Add same rights to the iusr-account that you did to the asp.net-account.