Hosting .NET CLR

http://www.codeproject.com/dotnet/simpleclrhost.asp

 

Sample Code for how to hosting the Common Language Runtime.

http://www.pek.com/blogs/pek/archives/2004/03/hosting_the_clr.php

 

CComPtr<ICorRuntimeHost> pRuntimeHost;
CorBindToRuntimeEx( NULL, SERVER_BUILD, CLR_FLAGS,
    __uuidof(CorRuntimeHost), __uuidof(ICorRuntimeHost), (void**) &pRuntimeHost );

pRuntimeHost->Start() ;
// CLR is now working…
pRuntimeHost->Stop();

.NET应用程序是如何开始运行的？

RT。相信很少有人考虑过这个问题。很神秘，但是说穿了的话，同样是一件很简单的过程。

 

这里需要引申出一个概念——runtime host，它其实只是一小段代码，用来启动我们熟悉的.NET应用程序。runtime host负责将运行时加载进process，并且创建一个默认的application domain，然后加载我们所写的代码到这个域中执行。我们比较熟悉的runtime host有ASP.NET，Microsoft Internet Explorer和Shell executables（启动Windows Application）。他们都是安装了.NET Framework之后默认的runtime host，我们也可以自己定义和开发runtime host。

 

一般来说，runtime host由unmanaged和managed两部分代码组成：unmanaged加载和配置通用语言运行时（common language runtime），并将控制权移交给managed部分，然后managed部分创建appdomain。

 

.NET Framework中除了我们熟悉的类库，其实还提供了一套Hosting APIs。加载运行时的关键就是CorBindToRuntimeEx函数（Mscoree.h），通过它我们可以设置所加载的runtime的版本，以及GC和所要加载的Assembly（至此，应用程序如何为.NET应用程序选择正确runtime的谜底被揭开了）。然后由ICorRuntimeHost来处理控制权到managed部分的转移。当然这个interface的功能不仅仅如此，更多的信息可以参考MSDN。

 

创建appdomain之前，runtime host需要确定如何为Domain来划定边界。边界的确定通常由如下的因素：对于某个类型的访问的限制，配置，安全性，以及对于Code的卸载。

 

结下来的一切就和我们自己写代码流程一样，为这个appdomain中加载并执行程序集（AppDomain.Load或Assembly.Load），至此，应用程序开始执行我们自己编写的User Code。（当然这其中还牵涉到一些CAS的问题）

在Autodesk的处女Coding所遇到的问题总结

今天和同事写了在Autodesk的第一个程序。虽然只是一个很简单的Test Demo，但是也非了我好大的周折。惭愧。CRT的诸如fopen、fread、fwrite之类的xx毕竟n久没有用了。编码问题也搞来搞去。我就说吧，还是.NET好，统一使用一个Unicode。 多省事。

 

然后还有一点不太甘心，就是我们在XP上写的.exe在Vista上面跑不起来，在shell explorer中打开就会报错，说什么“Side by Side”错误，要用sxstrace.exe来获取详细信息。找了一个据说曾经研究过Side by Side的同事来帮忙，结果忙了一圈还是没搞定，郁闷。为了这么一个简单程序而耗上一天实在不值得。结果当然是不了了之。源代码搬到Vista上，用VS2005重新编译了下，就算交工了。

 

晚上网上查了很多资料，终于搞清楚了。原来在.NET上使用GAC来部署强签名Assembly的技术来解决DLL Hell的方法，在Win32的应用程序也有了对应的技术，Isolated Application Model和Side by Side程序集部署方式。

 

所谓Isolated Application Model，就是VC2005编译出来的Native程序是一个个隔离的自我描述的程序集。通常使用一个assemblyname.exe.menifest来实现这个自我描述，其实就是一个XML文件。里面记录了该应用程序将要Dependent的Assembly的信息。

注：默认情况下，这个menifest是被嵌入到.exe中去的。我们可以通过设置项目属性，Menifest Tool，Embed Menifest设计为NO，这样编译后，menifest将会被输出。编辑这个menifest，我们就可以手工对应用程序的Dependency进行设置了。

 

此外对于Side by Side错误的详细信息，我们可以通过Vista中的Event Viewer来查阅，它给出了SxS错误的详细信息，包括了无法找到的Dependency的程序集名称等等。

 

最后，关于我们所遇到的问题，只要将C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT下的dll随.exe一起发布就可以了，这正是我们所需要的dll。因为Windows总是先从当前目录开始搜索，然后再是WinSxs和GAC。

 

ok..就总结这么多了，睡觉先。。

 

[引用]

http://msdn2.microsoft.com/en-us/library/ms682600.aspx

http://msdn2.microsoft.com/en-us/library/aa375193.aspx

http://www.codeguru.com/forum/showthread.php?t=408061

http://blogs.msdn.com/junfeng/archive/2006/04/14/576314.aspx

http://blogs.msdn.com/junfeng/archive/2006/01/24/517221.aspx#531208

.NET Obfuscator

Obfuscator（代码混淆）是一种防止.NET程序集被逆向工程（Reverse Engineering）的有效方法。 传统的代码混淆技术有重命名代码中的Class、Method、Variable的名称；在不影响代码逻辑的前提下，更改代码行的顺序。这可以使得被逆向工程后的代码逻辑不容易被破解。

在Visual Studio 2005中集成了Dotfuscator Community Edition工具就是用来对开发后的程序集进行代码混淆的，根本原理就是重命名。但是他的强大之初是加入了Overload Induction功能，也就是说它能够最大程度的利用Trivial Identifier（替换原有名称的一个标识符）。

private void CalcPayroll(SpecialList employeeGroup) {
   while (employeeGroup.HasMore()) {
        employee = employeeGroup.GetNext(true);
        employee.UpdateSalary();
        DistributeCheck(employee);
    }
}
处理之后如下：

private void a(a b) {
    while (b.a()) {
        a = b.a(true);
        a.a();
        a(a);
    }
}

以上只是说明了Obfuscator的原理，其实Obfuscator是在MSIL层面上对代码进行重命名的。重命名后的MSIL功能上等同于未重命名的MSIL。除了增加了代码混淆的程度，Obfuscator也使得程序集的尺寸变得更小了，因为Trivial Identifier通常都是单个无意义的字符。

目前Dotfuscator有3个版本，CE（Community Edition）、STD（Standard Edition）、PRO（Professional Edition）。Visual Studio 2005中集成的是CE版，其功能限制很大，基本无法用于商业用途。但是对于个人学习已经足够了。

Learning WPF 4

WPF应用程序分类：Standalone WPF Application、XBAP（XAML Browser Application）、XPS Document。

 

XBAP
XBAP总是通过ClickOnce来安装的。在打开http://ttpdownload.bl.uk/browserapp.xbap时，可以看到下载进度。一般来说，XBAP应用程序都是使用导航界面的。在IE7中，XBAP使用浏览器的前进和后退按钮，而在IE6中，XBAP使用自己的前进后退按钮。由于XBAP通过Internet部署，所以对它当然有很多的限制。如下：

• 无法创建独立的窗口。
• 无法显示应用程序定义的对话框。
• 无法在XBAP中显示Save对话框。
• 无法访问超出隔离区域的文件系统。
• 无法作为UI Automation的客户端。
• 由于WCF需要Full Trust，所以XBAP无法使用它。但是可以通过使用ASP.NET Web Service同样可以实现相同的功能。
• 无法进行平台互操作。
• 无法访问非托管的代码。

Why XPS in WPF？
XPS是使用XAML来定义的。从Windows Vista开始，XPS成为了Windows中打印格式。

XPS可以使用W3C的XML定义和X.509来签名。其存储格式由OPC（Open Packaging Conventions）定义。OPC制定了XML文档中的各个不同的部分是如何关联的，以及该如何存储于标准的ZIP格式的文档中。Microsoft Office 2007也是使用OPC来定义其文档格式。WPF应用程序可以在OPC层对文档进行操作，这样就可以更一般话的访问由OPC定义的所有文档类型。 

 

XBAP VS. Silverlight

Silverlight并不属于.NET Framework 3.0的一部分，WPF中的大部分功能都不支持。XBAP的运行需要.NET Framework 3.0的支持，客户机上必须安装WPF。所以续前两篇，http://ttpdownload.bl.uk/browserapp.xbap并不是Silverlight做的，这也是为什么上次麦当很惊奇地和我说，他运行这个程序，浏览器提示需要安装.NET Framework 3.0。