Friday, February 13, 2009

Using .Net in GINA . WebServices, remoting, XML etc.,

Microsoft states:

Do not use high level languages, libraries, frameworks, virtual machines or runtimes in core operating system processes

We recommend that you only use C languages and Win32 APIs for any add-in components that are loaded by core operating system processes. Two examples of core operating system processes are Winlogon.exe and Lsass.exe. 

The behavior of any high-level language, framework, or runtime in the components that are loaded by core operating system processes is undefined. For example, the Microsoft .NET Framework and the common language runtime were not designed to run in the context of core operating system processes. The following is a partial list of high-level languages, frameworks, and runtimes where the behavior is undefined in the context of core operating system processes: 


.NET Framework languages
C#
Visual Basic .NET
Managed Extensions for C++
common language runtime
Java
Microsoft Component Object Model (COM)
Microsoft COM+
Microsoft Distributed Component Object Model (DCOM) 
Microsoft Foundation Classes (MFC)
Microsoft ActiveX Template Library (ATL) framework


Well, we discovered several glitches with .NET usage inside winlogon process.

The most annoying  thing was  "Configuration system failed to initialize" exception ,  when using anything XML-related.

The exact reason for this error  is not quote clear as there is  no reasonable CLR debugger to  debug CLR code . But  what  is clear is the fact that .Net cannot find config files inside winlogon process. No wonders here as we are under System account which does not have interactive profile created. 

After  some research  using Reflector -  (a brilliant tool ,  btw ) and searching the web we have found the solution to this problem . Altho  applied to ASP,  it was suitable to  our case as well.

After  some modifications we have made it like this:


I used code formatting for the web to present the code.




using System;
using System.Configuration;
using System.Configuration.Internal;
using System.Reflection;
using System.Security;
using System.Security.Permissions;
using System.Windows.Forms;
using Utils;

namespace CfgReplace
{

public class ReplacementConfigSystem : IInternalConfigSystem
{
public static void InstallHook()
{
ReplacementConfigSystem rcs = new ReplacementConfigSystem();
rcs.InstallUsingInternalMethod();
}

private Configuration _base;
private IInternalConfigSystem _original;
private readonly string _appPath;
private Configuration _WSEConfiguration;

/// <summary>
/// Create an object that wraps a Configuration object and can plug into
/// ConfigurationManager.
/// </summary>
public ReplacementConfigSystem()
{

_base = ConfigurationManager.OpenMachineConfiguration();
_appPath = Help.GetAppPath() + "xxx.dll";
_WSEConfiguration = ConfigurationManager.OpenExeConfiguration(_appPath);
}

public void InstallUsingInternalMethod()
{

const BindingFlags flags = BindingFlags.Static | BindingFlags.NonPublic;
Type configManType = typeof(ConfigurationManager);
configManType.InvokeMember("s_initState", flags | BindingFlags.SetField, null, null, new object[] { 0 });
configManType.InvokeMember("SetConfigurationSystem", flags | BindingFlags.InvokeMethod, null, null, new object[] { this, true });

}

#region IInternalConfigSystem Members
/// <summary>
/// Return the requested Section from the Configuration object.
/// Sections are handled differently by ConfigurationManager, so
/// this method reconstructs the Section in an appropriate manner.
/// </summary>
/// <param name="configKey">Key name</param>
/// <returns></returns>
public object GetSection(string configKey)
{

ConfigurationSection section = //get the section from what ever place you want
return section;

}

public void RefreshConfig(string sectionName)
{

_base = ConfigurationManager.OpenExeConfiguration(_appPath);
}

public bool SupportsUserConfig
{

get
{

return false;
}
}
#endregion
}
}




No comments:

Post a Comment