I want to write a small installer app that installs a web site and creates IIS virtual directories. The app should run on Windows XP/Server 2003 (IIS 6) as well as on Vista/2008 (IIS 7).
The problem is: for IIS 6 we create virt dirs by calling WMI/Metabase API, for IIS 7 there is a much better API: Microsoft.Web.Administration, but its assembly is available only on IIS 7 systems.
Naive approach:
...
if (OperatingSystem == old)
{
call metabase API...
}
else
{
call Microsoft.Web.Administration...
}
...
Nice, isn't it? But how can I make sure that this does not crash on a old system just while trying to load the Microsoft.Web.Administration DLL? Or is an assembly just loaded, when it is first used? When a method that is calling into the assembly is first used?
I guess, testing does not help without some determinism being guaranteed by CLR/.NET spec.
I am really looking forward to hearing your experiences, hints or solutions for this topic. I have not found anything remotely usable on the web so far.
I have not been able to find the definitive answer as in a specification stating when assemblies must and must not be loaded. However, according to
http://msdn.microsoft.com/en-us/magazine/cc163655.aspx (section "Load Fewer Modules at Startup")
and the book extract at www.informit.com/articles/article.aspx?p=30601&seqNum=5 (extract from "Essential .NET, Volume I: The Common Language Runtime").
the JIT of the CLR will load a needed assembly only when needed to compile a method. Thus, you should move any use of Microsoft.Web.Administration... to a seperate method which is only called when your confident that the assembly exists on the system. That is,
setup()
{
if ( Operating.System == Old )
call metabase API
else
doIIS7Setup()
}
void doIIS7Setup()
{
call Microsoft.Web.Administration ....
}
Personally, rather than trying to rely on any inbuilt behaviour of the JIT, I'd move the dependency on Microsoft.Web.Administration to another assembly altogether.
Then, somewhere in the calling assembly, I'd check to see if %systemroot%\inetsrv\Microsoft.Web.Administration.dll is present. If so, then I'd assume I'm using the managed interface and call the assembly; if not, I'd revert to the metabase API.
Related
I'd like to use a piece of Windows 10 specific UWP API (specifically, the Windows.Graphics.Printing3D stuff) in an ASP.NET code-behind DLL. Is there any way to do so?
While looking for a .NET-only resolution to this one, I've found a moderately clean way - a Win32/64 C++ DLL that would consume UWP API and present a COM- or P/Invoke-based interface to .NET.
Create a regular Win32 DLL. Build an interface for .NET to consume - exported functions or objects, depends. In my case, a single exported function will do. In the project's C/C++ settings, make the following changes:
Under General, set Consume Windows Runtime Extensions to Yes.
Under General, set Additional #using Directories to: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcpackages;C:\Program Files (x86)\Windows Kits\10\UnionMetadata (assuming Visual Studio 2015)
Under Code Generation, set Enable Minimal Rebuild to No (it's only Yes for Debug, not for Release).
Then instantiate and use UWP components in the DLL in the usual C++/CX manner, like you would in a Store app, via using namespace Windows::... and ref new.
In this approach, you lose bitness agnosticism; an unmanaged DLL can't be "Any CPU". You win some, you lose some. Also, the site will not run without the Visual C++ redistributable package on the system. On the other hand, it may run faster than a .NET app; less managed/native boundary crossings.
Inspiration: "Using C++/CX in Desktop apps" by Pavel Y.
Open the project file as XML, and paste the following line under the first <PropertyGroup>:
<TargetPlatformVersion>10.0</TargetPlatformVersion>
Once you do that, the Add reference dialog will include UWP libraries, and the file type options in the "Browse..." dialog there will include .winmd.
Load the project, do Add reference/Browse, locate C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd, add that.
There are some helpful extension methods in the managed assembly System.Runtime.WindowsRuntime (e. g. IBuffer.AsStream()), but for some reason, it's not listed under Assemblies. To reference it, you'd need to edit the project file directly, and under the first <ItemGroup>, add the following:
<Reference Include="System.Runtime.WindowsRuntime" />
Unlike the guide states, you don't need to change the compilation target to x86 or x64; leave AnyCPU be.
For desktop .NET applications, this is sufficient. For ASP.NET, however, there's a catch. The way the ASP.NET runtime sets up its AppDomains not compatible with UWP. It's probably a bug deep down, but I've reported it, and a Microsoft rep said the whole thing was not a supported scenario to begin with.
Anyway, you have to change the LoaderOptimization policy of the AppDomain to SingleDomain. The quickest way to do so is via abusing a private method of AppDomain:
AppDomain ad = AppDomain.CurrentDomain;
MethodInfo mi = ad.GetType().GetMethod("SetupLoaderOptimization", BindingFlags.Instance | BindingFlags.NonPublic);
mi.Invoke(ad, new object[] { LoaderOptimization.SingleDomain });
A good place to do that would be in the app startup code.
A slightly less dangerous approach would involve creating a new AppDomain, which would inherit all setup properties from the current one but LoaderOptimization, which will be set to SingleDomain, and running the UWP dependent code in that domain. Like this:
AppDomain CreateUnsharingDomain()
{
AppDomain cad = AppDomain.CurrentDomain;
AppDomainSetup cads = cad.SetupInformation;
return AppDomain.CreateDomain("Dummy", cad.Evidence,
new AppDomainSetup
{
ApplicationName = cads.ApplicationName,
ApplicationBase = cads.ApplicationBase,
DynamicBase = cads.DynamicBase,
CachePath = cads.CachePath,
PrivateBinPath = cads.PrivateBinPath,
ShadowCopyDirectories = cads.ShadowCopyDirectories,
ShadowCopyFiles = cads.ShadowCopyFiles,
ApplicationTrust = cads.ApplicationTrust,
LoaderOptimization = LoaderOptimization.SingleDomain
});
//Not sure which other properties to copy...
}
CreateUnsharingDomain().DoCallBack(MyUWPDependentMethod);
Again, it would make sense to create the domain once and cache it for the app lifetime.
This approach might be faster than the one with the monkey-patched AppDomain. The MultiDomain optimization exists for a reason; if you leave most of the Web code in a MultiDomain world, the optimization will do its work as intended.
Inspiration: "Walkthrough: Using WinRT libraries from a Windows Desktop application" by David Moore.
Background: I have a DLL I created that includes 2 c files. These c files reference a third c file which defines a user defined type (we'll call it class_pointer), which is a pointer of type class.
E.g.
typedef class pointer_class *class_pointer;
then defines the class:
typedef class pointer_class {..}
pointer_class has various variables and functions associated with it that the original 2 c files make use of through class_pointer.
I am using this DLL in an ASP.NET C# web application. I am using PInvoke to import the functions into the dll. However, when I go to call on these functions that involve the class_pointer, the website running on IIS hangs. This does not happen in the VS debugger. If I comment out said class_pointers, everything runs smoothly -- I have access to the DLL and everything.
I have tried changing the permissions on all the DLLs included in my bin directory (just to be safe) for NETWORK SERVICE to have read/execute permissions. The dll will work without the class_pointers, so I don't think it is an issue of permissions. Does anyone have any advice on what might be causing IIS to hang when these class_pointers are involved?
I finally was able to figure this out with the help of Microsoft's debugging tools.
The class_pointers were written by another developer that has since left the place I work. In the pointer_class, there was a function to get the current application path. When running on the web, this was set to the inetsrv directory in SYSWOW64 (The machine I was running on was a 64bit machine). To solve the issue, we set the application path to the website when we are running the web, rather than where the .exe application was running from (SYSWOW64/inetsrv).
Because the application path was wrong, the native dll was unable to load some files in and was putting up popup warning messages. These pop up messages were waiting for a user response and since we couldn't get one on the web, the application hanged!
Hope this helps someone else out there!
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'd like to show a list of all used assemblies on a dedicated web page inside a ASP.NET web application for debugging and maintainance purposes (there are many instances of this web application on many different servers). The assemblies could be called from the bin folder or from the GAC. There are some written by myself, but also third-party assemblies.
Is there a simple, automated way to get a list of all loaded or referenced assemblies of the web application including the version number (calling System.Reflection.Assembly - GetName().Version ...)? Do I have to explicitly pass all assembly names for version check or could I retrieve them automatically? Do I have to use Reflection for a comprehensive list of dependencies/references?
I think you can use AppDomain.CurrentDomain.GetAssemblies() for this, e.g something like this:
foreach (System.Reflection.Assembly a in AppDomain.CurrentDomain.GetAssemblies())
{
Response.Write(a.FullName + "<br/>");
}
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.