我目前正在使用Microsoft.Web.Administration(MWA)命名空间,以便调整我们的应用程序以使用新API配置IIS 7.5.我知道所有IIS级别的更改都应该在以下文件中表示(我在Win2K8-R2上):
%WINDIR%\System32\inetsrv\config\applicationHost.config
因此,当我使用该ServerManager对象提交配置更改时,应相应地更新该文件.
添加新的MIME类型(使用MWA编程)后,我没有看到任何更改applicationHost.config file,但我确实在IIS管理器窗口中看到了新的MIME类型,IIS可以正确识别此MIME类型.即使在重新启动操作系统后 - 配置文件也不包含新添加的MIME类型,但IIS管理器窗口会列出它.
因为我的应用程序池被强制为32位(Enable32BitAppOnWin64 = true),我认为相关的配置文件应位于%WINDIR%\SysWOW64\inetsrv\Config,但(如果它存在...) - 它也不会在代码提交更新后更改.
有人可以解释一下吗？我错过了什么(可能会查看错误的文件？)？有人可以对SysWOW64\inetsrv\config目录有所了解吗？
这是我添加MIME类型的代码:
ServerManager manager = new ServerManager();
ConfigurationElementCollection staticContentCollection = manager
.GetApplicationHostConfiguration()
.GetSection("system.webServer/staticContent")
.GetCollection();
//MIMETypes is a string[] array, each object is {FileExt},{MIMETypeStr}
foreach (string pair in MIMETypes)
{
string[] mimeProps = pair.Split(',');
ConfigurationElement mimeTypeEl = staticContentCollection
.Where(a =>
(string)a.Attributes["fileExtension"].Value == mimeProps[0])
.FirstOrDefault();
if (mimeTypeEl != null)
{
staticContentCollection.Remove(mimeTypeEl);
}
ConfigurationElement mimeMapElement =
staticContentCollection.CreateElement("mimeMap");
mimeMapElement["fileExtension"] = mimeProps[0]; …我已经完成了一项任务,即放弃我们产品的一个dll,并用一个纯C#替换它.旧的DLL是.NET 2.0托管C++(C++\CLI),它包含对Win32本机Crypto API的调用.新的DLL应该公开一个具有相同名称和方法的新对象,但应该用C#(.NET 4.0)编写.当然,新的DLL应该以与旧的DLL相同的方式加密(和解密) - 否则,所有保存的加密密码都在持久存储中,如在数据库或文件中 - 将无法解决!
这是本机(Win32)API调用的(伪)代码(请注意,输入始终是Unicode编码的):
//buffer_to_encrypt - Is the input to the following procedure and is the buffer
// to be encrypted using 3DES and the below password to generate a valid 3DES key
// The buffer is Unicode encoded!!!
HCRYPTPROV m_provider = NULL;
HCRYPTHASH m_hash = NULL;
HCRYPTKEY m_key = NULL;
static const unsigned char password[] = {
0xF1, 0x49, 0x4C, 0xD0, 0xC1,
0xE2, 0x1A, 0xEA, 0xFB, 0x34,
0x25, 0x5A, 0x63, 0xA5, 0x29,
0x09, 0x8E, …我开发了一个.NET程序集(.NET 4.0,强名称),它公开了两个服务组件.程序集(dll)应该托管在COM +应用程序中,并使用COM +属性(程序集和组件级别)进行修饰.例如,程序集级别属性:
//COM+ Attributes
[assembly: ApplicationID("MY_APP_GUID")] //GUID of the COM+ app
[assembly: ApplicationName("MyComPlusAppName")] //Name of the COM+ app
[assembly: ApplicationActivation(ActivationOption.Server)] //The app is hosted in it own dllhost process (out-of-process)
[assembly: ApplicationAccessControl(AccessChecksLevel = AccessChecksLevelOption.ApplicationComponent, Authentication = AuthenticationOption.None, ImpersonationLevel = ImpersonationLevelOption.Delegate, Value = false)]
[assembly: Description("COM+ app description")]
目前(开发原因),我一直在运行以下脚本来创建COM +应用程序并注册程序集(包含其所有组件):
%windir%\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe /appdir:"%CD%" MyComPlusAssembly.dll
上面的批处理文件将根据程序集装饰属性创建(在单次运行中)COM +应用程序,在COM +应用程序中注册MyComPlusAssembly.dll文件并在其中注册所有ComVisible组件,因此所有内容都可见并在dcomcnfg中按预期配置.此命令还将生成一个全新的TLB文件.程序集是使用AnyCPU构建的,因此在x64版本的Windows上,dllhost.exe进程将以64位运行,而在x86版本的Windows上,它将以32位运行.另外,我的dll文件,应该不放在GAC(这就是为什么我使用Regsvcs.exe的命令行实用程序的/ APPDIR开关).使用上述批处理文件安装COM +程序集时,所有工作都按预期工作.
我开始为我的应用程序编写一个Wix(v3.6)部署项目,它应该做同样的事情,即:创建COM +应用程序,注册.NET程序集和所有ComVisible组件.请注意,这次我依赖于TLB文件随安装程序一起提供(*.msi).TLB由构建过程生成(VS 2010).为实现上述目的,我添加了以下Wix组件(受Wix COM +扩展文档的启发 - WixComPlusExtension):
<DirectoryRef Id="INSTALLDIR_SERVER">
<Component Id="cmp_MyComPlusAssembly.dll" Guid="COMPONENT_DLL_GUID">
<File Id="MyComPlusAssembly.dll" Name="MyComPlusAssembly.dll" DiskId="1" Source="..\install\$(var.Configuration)\Server\MyComPlusAssembly.dll" KeyPath="yes"/>
<CreateFolder> …