上面那句導(dǎo)致的錯(cuò)誤catch無(wú)法捕獲。運(yùn)行時(shí)候?yàn)g覽器中顯示如下錯(cuò)誤:
=================================
File or assembly name System, or one of its dependencies, was not found.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileNotFoundException: File or assembly name System, or one of its dependencies, was not found.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine why the assembly 'System' could not be loaded.
=== Pre-bind state information ===
LOG: DisplayName = System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
(Fully-specified)
LOG: Appbase = file:///E:/wwwroot/aspxuser/hahahawk.17163.com
LOG: Initial PrivatePath = bin
Calling assembly : Wrox.WebModules.FileManager.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Publisher policy file is not found.
LOG: No redirect found in host configuration file (C:\WINNT\Microsoft.NET\Framework\v1.0.3705\aspnet.config).
LOG: Using machine configuration file from C:\WINNT\Microsoft.NET\Framework\v1.0.3705\config\machine.config.
LOG: Post-policy reference: System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files/root/646c7f18/82ce05e1/System.DLL.
LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files/root/646c7f18/82ce05e1/System/System.DLL.
LOG: Attempting download of new URL file:///E:/wwwroot/aspxuser/hahahawk.17163.com/bin/System.DLL.
LOG: Attempting download of new URL file:///E:/wwwroot/aspxuser/hahahawk.17163.com/bin/System/System.DLL.
LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files/root/646c7f18/82ce05e1/System.EXE.
LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files/root/646c7f18/82ce05e1/System/System.EXE.
LOG: Attempting download of new URL file:///E:/wwwroot/aspxuser/hahahawk.17163.com/bin/System.EXE.
LOG: Attempting download of new URL file:///E:/wwwroot/aspxuser/hahahawk.17163.com/bin/System/System.EXE.
Stack Trace:
]]>
使用ASP在IIS創(chuàng)建WEB站點(diǎn)的函數(shù)
|
在VS2010 中,你默認(rèn)建立的 WPF 程序就是.Net Framework 4 Client Profile ,而不是.Net Framework 4。昨天下午到今天早上,我在為 System.Web 無(wú)法引用而苦惱的問(wèn)題,就是它導(dǎo)致的。
VS2010中,我們?cè)陧?xiàng)目的屬性下,可以看到項(xiàng)目有以下多種 Target framework 屬性。
我今天碰到的 Sytem.Web 引用問(wèn)題如下:
在用 VS2010 Beta2 書(shū)寫(xiě)一個(gè)WPF應(yīng)用的時(shí)候,要使用 System.Web.HttpUtility.UrlEncode()方法時(shí),發(fā)現(xiàn)竟然無(wú)法增加對(duì) System.Web 的引用。如下圖:
.NET Reference 中沒(méi)有 System.Web 組件。
使用 Browse 方式打開(kāi)指定目錄的文件 C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Web.dll 也不行。
如下圖:
GAC 中也沒(méi)有 4.0 版本的 System.Web 組件,如下圖:
強(qiáng)制添加 C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Web.dll 到GAC 時(shí)會(huì)報(bào)錯(cuò)誤:
---------------------------
Cannot Add Assembly
---------------------------
Unable to add the selected assembly. The assembly must have a strong name (name, version and public key).
---------------------------
確定
---------------------------
這個(gè)文件的信息如下:
但是VS2010 Beta2 建立的 Web 項(xiàng)目,默認(rèn)就有 System.Web 的引用,這里沒(méi)有任何問(wèn)題,如下圖:
查看這時(shí)候的 System.Web 屬性,如下:
把 C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Web.dll 放入 GAC也會(huì)報(bào)錯(cuò)誤:
---------------------------
Cannot Add Assembly
---------------------------
Unable to add the selected assembly. The assembly must have a strong name (name, version and public key).
---------------------------
確定
---------------------------
日前微軟推出了基于.NET Framework 2.0開(kāi)發(fā)的Petshop 4。新的Petshop4實(shí)現(xiàn)了與Petshop 3相同甚至更多的特性,由于采用了Master Pages,Membership,以及Profile,SqlCacheDependency,但是代碼量卻減少了四分之一。同時(shí),在事務(wù)、數(shù)據(jù)緩存、安全方面使用了.NET 2.0附帶的特性,構(gòu)建了一個(gè)靈活的最佳實(shí)踐的應(yīng)用程序。
他們利用了Project Conversion Wizard把項(xiàng)目從ASP.NET 1.1移植到了ASP.NET 2.0,然后做了以下改動(dòng):
1.用System.Transactions代替了原來(lái)的Serviced Components提供的事務(wù)功能
代碼實(shí)現(xiàn):PetShop.BLL.OrderSynchronous 的 public void Insert(PetShop.Model.OrderInfo order)。
2.用強(qiáng)類(lèi)型的范型集合代替了原來(lái)的弱類(lèi)型集合
public IList<ProductInfo> GetProductsByCategory(string category)
{
// Return new if the string is empty
if (string.IsNullOrEmpty(category))
return new List<ProductInfo>();
// Run a search against the data store
return dal.GetProductsByCategory(category);
}
3.采用ASP.NET 2.0 Membership來(lái)做認(rèn)證和授權(quán)
4.創(chuàng)建了針對(duì)Oracle 10g的Custom ASP.NET 2.0 Membership Provider
5.利用ASP.NET 2.0的Custom Oracle 和 SQL Server Profile Providers 做用戶(hù)狀態(tài)管理,包括購(gòu)物車(chē)等
6.采用了Master Pages,取代了原來(lái)的用戶(hù)控件,來(lái)實(shí)現(xiàn)統(tǒng)一的界面效果
7.使用了ASP.NET 2.0 Wizard控件實(shí)現(xiàn)check-out
8.使用了SqlCacheDependency來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)層次的緩存更新(cache invalidation)功能
9.使用了消息隊(duì)列來(lái)實(shí)現(xiàn)異時(shí)訂單處理。
2.整體架構(gòu):
數(shù)據(jù)庫(kù):(暫略)
項(xiàng)目列表:從整體可以看出,Pet Shop 4的項(xiàng)目體系已經(jīng)很龐大,考慮的方面也較3.0更全面復(fù)雜。
序號(hào) |
項(xiàng)目名稱(chēng) |
描述 |
1 |
BLL |
業(yè)務(wù)邏輯層 |
2 |
CacheDependencyFactory |
緩存依賴(lài)類(lèi)的工廠(chǎng)類(lèi) |
3 |
WEB |
表示層 |
4 |
DALFactory |
數(shù)據(jù)層的抽象工廠(chǎng) |
5 |
DBUtility |
數(shù)據(jù)訪(fǎng)問(wèn)類(lèi)組件 |
6 |
IBLLStrategy |
同步/異步策略接口 |
7 |
ICacheDependency |
緩存依賴(lài)類(lèi)接口 |
8 |
IDAL |
數(shù)據(jù)訪(fǎng)問(wèn)層接口定義 |
9 |
IMessaging |
異時(shí)處理消息隊(duì)列接口定義 |
10 |
IProfileDAL |
Profile的數(shù)據(jù)訪(fǎng)問(wèn)層接口定義 |
11 |
Membership |
Membership認(rèn)證和授權(quán)管理 |
12 |
MessagingFactory |
異時(shí)處理消息隊(duì)列的抽象工廠(chǎng) |
13 |
Model |
業(yè)務(wù)實(shí)體 |
14 |
MSMQMessaging |
異時(shí)處理消息隊(duì)列的實(shí)現(xiàn) |
15 |
OracleDAL |
Oracle數(shù)據(jù)訪(fǎng)問(wèn)層 |
16 |
OracleProfileDAL |
Oracle的Profile Providers 做用戶(hù)狀態(tài)管理,包括購(gòu)物車(chē)等 |
17 |
OrderProcessor |
后臺(tái)處理進(jìn)程,處理訂單隊(duì)列 |
18 |
Profile |
Profile的數(shù)據(jù)訪(fǎng)問(wèn)層 |
19 |
ProfileDALFactory |
ProfileDAL的工廠(chǎng)類(lèi)(反射創(chuàng)建ProfileDAL) |
20 |
SQLProfileDAL |
SQL Server 的Profile Providers 做用戶(hù)狀態(tài)管理,包括購(gòu)物車(chē)等 |
21 |
SQLServerDAL |
SQLServer數(shù)據(jù)訪(fǎng)問(wèn)層 |
22 |
TableCacheDependency |
緩存依賴(lài)實(shí)現(xiàn)類(lèi) |
項(xiàng)目分解:
由于整體已經(jīng)有22個(gè)項(xiàng)目,所以,對(duì)于初學(xué)者一看就暈了,所以,我做了分解,可以大體上分幾塊去理解。
序號(hào) |
項(xiàng)目名稱(chēng) |
描述 |
1 |
WEB |
表示層 |
2 |
Model |
業(yè)務(wù)實(shí)體 |
3 |
BLL |
業(yè)務(wù)邏輯層 |
4 |
DALFactory |
數(shù)據(jù)層的抽象工廠(chǎng) |
5 |
IDAL |
數(shù)據(jù)訪(fǎng)問(wèn)層接口定義 |
6 |
SQLServerDAL |
SQLServer數(shù)據(jù)訪(fǎng)問(wèn)層 |
7 |
OracleDAL |
Oracle數(shù)據(jù)訪(fǎng)問(wèn)層 |
8 |
DBUtility |
數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)組件基礎(chǔ)類(lèi) |
9 |
CacheDependencyFactory |
緩存依賴(lài)類(lèi)的工廠(chǎng)類(lèi) |
10 |
ICacheDependency |
緩存依賴(lài)類(lèi)接口 |
11 |
TableCacheDependency |
緩存依賴(lài)實(shí)現(xiàn)類(lèi) |
12 |
IBLLStrategy |
同步/異步處理策略接口(實(shí)現(xiàn)在bll根據(jù)配置反射選擇) |
13 |
MessagingFactory |
異時(shí)處理消息隊(duì)列的抽象工廠(chǎng) |
14 |
IMessaging |
異時(shí)處理消息隊(duì)列接口定義 |
15 |
MSMQMessaging |
異時(shí)處理消息隊(duì)列的實(shí)現(xiàn) |
16 |
Profile |
Profile的數(shù)據(jù)訪(fǎng)問(wèn)層 |
17 |
ProfileDALFactory |
ProfileDAL的工廠(chǎng)類(lèi)(反射創(chuàng)建ProfileDAL) |
18 |
IProfileDAL |
Profile的數(shù)據(jù)訪(fǎng)問(wèn)層接口定義 |
19 |
OracleProfileDAL |
Oracle的Profile Providers 做用戶(hù)狀態(tài)管理 |
20 |
SQLProfileDAL |
SQL Server 的Profile Providers 做用戶(hù)狀態(tài)管理 |
21 |
Membership |
Membership認(rèn)證和授權(quán)管理 |
22 |
OrderProcessor |
后臺(tái)處理進(jìn)程,處理訂單隊(duì)列 |
3.Petshop 4中的設(shè)計(jì)模式:
工廠(chǎng)模式:
首當(dāng)其沖的就是工廠(chǎng)模式,很容易就可以看出來(lái),也是應(yīng)用最多的。
DALFactory:數(shù)據(jù)訪(fǎng)問(wèn)層的抽象工廠(chǎng)(決定創(chuàng)建哪種數(shù)據(jù)庫(kù)類(lèi)型的數(shù)據(jù)訪(fǎng)問(wèn)層。可以選擇:SQLServer,Oracle)
CacheDependencyFactory:緩存依賴(lài)類(lèi)的工廠(chǎng)類(lèi)。(創(chuàng)建具體表的緩存依賴(lài))
MessagingFactory :異時(shí)處理消息隊(duì)列的抽象工廠(chǎng)(反射創(chuàng)建具體的異時(shí)處理類(lèi))
ProfileDALFactory:ProfileDAL的工廠(chǎng)類(lèi)(反射選擇創(chuàng)建Oracle 和SQL Server的 ProfileDAL)
]]>中圖分類(lèi)號(hào):TP311文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):1009-3044(2010)17-4660-04
Based on .Net Framework's Research and Development about Web Management System (C#)
CHEN Zhao-yun, DONG Hai-yan, ZHOU Yong-fu
(Heyuan Vocational Technical College of Electronics and Information Engineering, Heyuan 517000, China)
Abstract: This composition introduces Users Manager System of Web in details from the system’s environment to the system’s framework and development’s technology.It can helps many programmers to solve the problems about C# programming、using components about .NET framwork、data Acquisition、databinding and so on.
Key words: C#; components; data Acquisition; databinding
Microsoft.NET Framework是微軟于2000年推出的用于構(gòu)建新一代Internet集成服務(wù)平臺(tái)的最新框架,這種集成服務(wù)平臺(tái)允許各種系統(tǒng)環(huán)境下的應(yīng)用程序通過(guò)互聯(lián)網(wǎng)進(jìn)行通信和共享數(shù)據(jù)。
]]>
Java runs on any platform with a Java VM. C# only runs in Windows for the foreseeable future.
.NET and J2EE offer pretty much the same laundry list of features, albeit in different ways.
By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers.
.NET is a good thing for those of you committed to Microsoft architectures.
.NET will undoubtedly become the default development environment for Microsoft platforms.
However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term.
It would be easy to dismiss .NET as more Microsoft marketing-ware and continue on your merry way. But don't.
[Microsoft is] fighting Java and open source initiatives on their own terms, putting their own spin on "open" and attempting to directly address the needs of developers.
If you consider yourself an evangelist for Java or open source platforms, then the nature of the war is changing. Be prepared.
Microsoft has put a stake in the ground with SOAP, and they're pushing hard to put something understandable and useful in the hands of developers. J2EE proponents need to do the same with their platform.
Even if you don't write code dedicated to Microsoft platforms, you have probably heard by now about Microsoft .NET, Microsoft's latest volley in their campaign against all things non-Windows. If you've read the media spin from Microsoft, or browsed through the scant technical material available on the MSDN site, or even if you attended the Microsoft Professional Developers' Conference (where the .NET platform was officially "launched"), you're probably still left with at least two big questions:
And, if you think more long-term, you might have a third question rattling around your head:
The .NET framework is at a very early stage in its lifecycle, and deep details are still being eked out by the Microsoft .NET team. But we can, nevertheless, get fairly decent answers to these questions from the information that's already out there.
First, let's get some concrete details. Here's one cut at an itemized list of the technical components making up the .NET platform:
What is it?
Current ruminations about .NET in various forums are reminiscent of the fable of the three blind men attempting to identify an elephant: It's perceived as very different things, depending on your perspective. Some see .NET as Microsoft's next-generation Visual Studio development environment. Some see it as yet another new programming language (C#). Some see it as a new data-exchange and messaging framework, based on XML and SOAP. In reality, .NET wants to be all of these things, and a bit more.
How do .NET and J2EE compare?
As you can see, the .NET platform has an array of technologies under its umbrella. Microsoft is ostensibly presenting these as alternatives to other existing platforms, like J2EE and CORBA, in order to attract developers to the Windows platform. But how do the comparisons play out item-by-item? One way to lay out the alternatives between .NET and J2EE is shown in the following table:
Microsoft.NET | J2EE | Key differentiators |
---|---|---|
C# programming language | Java programming language | C# and Java both derive from C and C++. Most significant features (e.g., garbage collection, hierarchical namespaces) are present in both. C# borrows some of the component concepts from JavaBeans (properties/attributes, events, etc.), adds some of its own (like metadata tags), but incorporates these features into the syntax differently.
Java runs on any platform with a Java VM. C# only runs in Windows for the foreseeable future. C# is implicitly tied into the IL common language runtime (see below), and is run as just-in-time (JIT) compiled bytecodes or compiled entirely into native code. Java code runs as Java Virtual Machine (VT) bytecodes that are either interpreted in the VM or JIT compiled, or can be compiled entirely into native code. |
.NET common components (aka the ".NET Framework SDK") | Java core API | High-level .NET components will include support for distributed access using XML and SOAP (see ADO+ below). |
Active Server Pages+ (ASP+) | Java ServerPages (JSP) | ASP+ will use Visual Basic, C#, and possibly other languages for code snippets. All get compiled into native code through the common language runtime (as opposed to being interpreted each time, like ASPs). JSPs use Java code (snippets, or JavaBean references), compiled into Java bytecodes (either on-demand or batch-compiled, depending on the JSP implementation). |
IL Common Language Runtime | Java Virtual Machine and CORBA IDL and ORB | .NET common language runtime allows code in multiple languages to use a shared set of components, on Windows. Underlies nearly all of .NET framework (common components, ASP+, etc.).
Java's Virtual Machine spec allows Java bytecodes to run on any platform with a compliant JVM. CORBA allows code in multiple languages to use a shared set of objects, on any platform with an ORB available. Not nearly as tightly integrated into J2EE framework. |
Win Forms and Web Forms | Java Swing | Similar web components (e.g., based on JSP) not available in Java standard platform, some proprietary components available through Java IDEs, etc.
Win Forms and Web Forms RAD development supported through the MS Visual Studio IDE - no other IDE support announced at this writing. Swing support available in many Java IDEs and tools. |
ADO+ and SOAP-based Web Services | JDBC, EJB, JMS and Java XML Libraries (XML4J, JAXP) | ADO+ is built on the premise of XML data interchange (between remote data objects and layers of multi-tier apps) on top of HTTP (AKA, SOAP). .NET's web services in general assume SOAP messaging models. EJB, JDBC, etc. leave the data interchange protocol at the developer's discretion, and operate on top of either HTTP, RMI/JRMP or IIOP. |
The comparisons in this table only scratch the surface. Here's an executive summary of .NET vs. J2EE:
Features: .NET and J2EE offer pretty much the same laundry of list of features, albeit in different ways.
Portability: The .NET core works on Windows only but theoretically supports development in many languages (once sub-/supersets of these languages have been defined and IL compilers have been created for them). Also, Net's SOAP capabilities will allow components on other platforms to exchange data messages with .NET components. While a few of the elements in .NET, such as SOAP and its discovery and lookup protocols, are provided as public specifications, the core components of the framework (IL runtime environment, ASP+ internals, Win Forms and Web Forms component "contracts", etc.) are kept by Microsoft, and Microsoft will be the only provider of complete .NET development and runtime environments. There has already been some pressure by the development community for Microsoft to open up these specifications, but this would be counter to Microsoft's standard practices.
J2EE, on the other hand, works on any platform with a compliant Java VM and a compliant set of required platform services (EJB container, JMS service, etc., etc.). All of the specifications that define the J2EE platform are published and reviewed publicly, and numerous vendors offer compliant products and development environments. But J2EE is a single-language platform. Calls from/to objects in other languages are possible through CORBA, but CORBA support is not a ubiquitous part of the platform.
By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers by allowing them to play in the Microsoft sandbox. Devotees of these languages are particularly amenable to gestures like this, since for the most part they have felt somewhat disenfranchised and marginalized in the Microsoft/Sun/Open Source wars. And by using XML and SOAP in their component messaging layer, Microsoft is bolstering their diplomatic face and adding an element of openness to their platform, providing ammunition against claims of proprietary behavior.
.NET is a good thing for those of you committed to Microsoft architectures. ASP+ is better than ASP, ADO+ is better, but different, than ADO and DCOM, C# is better than C and C++. The initial version of .NET won't be real until sometime in 2001, so you have some time to prepare, but this will undoubtedly become the default development environment for Microsoft platforms. And if you're developing within the Microsoft development framework now, you will undoubtedly benefit from adopting elements of the .NET framework into your architectures.
However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term. The IL common language runtime, for example, has some fairly significant hurdles to overcome before it has any real payoff for developers. Each language that wants to integrate with the component runtime has to define a subset/superset of the language that maps cleanly into and out of the IL runtime, and has to define constructs that provide the component metadata that IL requires. Then compilers (x-to-IL and IL-to-x) will have to be developed to both compile language structures (objects, components, etc.) into IL component bytecodes, and also generate language-specific interfaces to
]]>第一步:下載.NET Mass Downloader.
第二步:下載.NET Framework3.5的安裝文件,這是完整的可再發(fā)行組件包。有190多MB,下載完成后,安裝它。
第三步:找到文件下載的目錄。例如,我把文件放在的C盤(pán)的跟目錄,文件的解壓后的目錄為C:\NetMassDownloader,然后我們運(yùn)行cmd.exe,指向我剛才解壓的目錄:
第四步:對(duì)NetMassDownloader的參數(shù)進(jìn)行設(shè)置,我是這樣設(shè)置的。
這條命令我解釋一下:
(1)-d C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727是我們安裝.net2.0時(shí),.net類(lèi)庫(kù)存放的文件夾。
(2)-output E:\NETFramework2.0是我們存放下載的.Net Framework的源代碼的文件夾。這個(gè)目錄你可以自定義,不一定非要和我寫(xiě)的一樣。
(3)-vsver 8.0表示我們要下載的源代碼的版本是.net2.0
netmassdownloader.exe還有其他一些參數(shù)可以設(shè)置,大家輸入netmassdownloader.exe /?就可以查看。在此就不羅嗦了。
參數(shù)配置好后,我們?cè)试S它,我們不要關(guān)閉它,.net framework的源代碼大概有120多MB,我們耐心等待就行了,在運(yùn)行的時(shí)候,可能會(huì)出現(xiàn)一些文件找不到的信息,我們不要管它。
第五步:源代碼下載完成后,我們開(kāi)始配置VS2005。
(1)按照我的截圖配置:
將啟用“僅我的代碼”(僅限托管)和要求源文件與原版本完全匹配的選項(xiàng)給去掉。
第六步:配置你的解決方案,以后如果你創(chuàng)建了新的解決方案,第六步也是少不了的。
在“包含源代碼的目錄”中設(shè)定E:\NETFramework2.0,就是我們下載的.net framework2.0的源代碼的目錄。
]]>服務(wù)器.netframework asp.net2.0每三分鐘報(bào)錯(cuò)|perflib1008。服務(wù)器上每三分鐘都會(huì)報(bào)錯(cuò):source Perflib ID:1008,請(qǐng)問(wèn)這個(gè)要如何解決呢?
事件類(lèi)型: 錯(cuò)誤
事件來(lái)源: Perflib
事件種類(lèi): 無(wú)
事件 ID: 1008
日期: 2007-9-26
事件: 13:46:46
用戶(hù): N/A
計(jì)算機(jī): REPORTSRV
描述:DLL "C:\WINNT\Microsoft.NET\Framework\v2.0.50727\aspnet_perf.dll" 中服務(wù)
"ASP.NET_2.0.50727" 的打開(kāi)過(guò)程出現(xiàn)故障。 該服務(wù)的性能數(shù)據(jù)將不可使用。返回的狀態(tài)碼 是數(shù)據(jù) DWORD 0。
數(shù)據(jù):0000: 05 40 00 80 .@.?
解決辦法:
回答:根據(jù)您的描述,我對(duì)這個(gè)問(wèn)題的理解是:Windows 2000 Server ,在日志中每隔3分鐘記錄Perflib 1008 的錯(cuò)誤事件。如果我的理解有誤,請(qǐng)告訴我。
這是由于沒(méi)有正確安裝aspnet的性能計(jì)數(shù)器的dll文件導(dǎo)致,建議您嘗試以下方法修復(fù):
1. 在命令行,輸入以下命令卸載mscoree.dll和aspnet_isapi.dll的注冊(cè)信息。
regsvr32 /u %windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
regsvr32 /u %windir%\System32\mscoree.dll
完成后重啟系統(tǒng)。
2. 如果卸載出錯(cuò),在命令行,定位到C:\WINNT\Microsoft.NET\Framework\v2.0.50727目錄,運(yùn)行以下命令:
aspnet_regiis.exe –ua 卸載ASP.NET
aspnet_regiis.exe –I 重新安裝
完成后,重啟系統(tǒng),查看是否還有問(wèn)題。建議您從添加刪除程序刪除所有.net framework,然后重啟系統(tǒng),重新安裝,看是否還有問(wèn)題。我意思是重新安裝.net framework,這個(gè)計(jì)數(shù)器是由Framework 提供的,重新安裝該組件,則可以重新創(chuàng)建計(jì)數(shù)器。
另外,這是ASP.NET的性能計(jì)數(shù)器無(wú)法使用,但不影響ASP.NET的使用,如果不使用性能計(jì)數(shù)器,您也可以禁用該計(jì)數(shù)器,更改以下注冊(cè)表鍵值:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_2.0.50727\Performance
"Disable Performance Counters"=dword:00000001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET\Performance
"Disable Performance Counters"=dword:00000001
【相干文章:Java的中文編程與配置心…】
【擴(kuò)大閱讀:蔡學(xué)鏞:編譯、反編譯、…】
以下便是ado.net新增的特性: 【擴(kuò)大信息:Web服務(wù)器和應(yīng)用程序服務(wù)…】
1. 批量復(fù)制操作(bulk copy operation)
將數(shù)值從一個(gè)數(shù)值源批量復(fù)制到另一個(gè)數(shù)值源是ado.net 2.0的一個(gè)新特性。批量復(fù)制類(lèi)提供了最快的要領(lǐng)把數(shù)值從一個(gè)數(shù)值源遷徙到另一個(gè)數(shù)值源。每個(gè)ado.net的數(shù)值提供者城市提供相應(yīng)的批量復(fù)制類(lèi)。例如,在sql.net數(shù)值提供者里,批量復(fù)制操作是由一個(gè)叫sqlbulkcopy的類(lèi)來(lái)完成的,它可以讀取一個(gè)dataset, datatable, datareader或xml 對(duì)象。
2.批量更新(batch update)
要是數(shù)值庫(kù)服務(wù)器支持批量更新特性,batch update代替了幾個(gè)短周期提交請(qǐng)求的方式,從而大大改善在一個(gè)短周期內(nèi)向服務(wù)器產(chǎn)生多個(gè)批量更新時(shí)的性能。updatebatchsize屬asp.net 工作流性提供在一批更新里要更新行數(shù)。這個(gè)屬性值能被限制到小數(shù)位。
<!-- Easy AdSense V2.92 --><!-- Post[count: 2] --> <!-- Easy AdSense V2.92 -->3.數(shù)值分頁(yè)
現(xiàn)在command對(duì)象具有一個(gè)新的執(zhí)行要領(lǐng)叫做executepagereader。這個(gè)要領(lǐng)有三個(gè)參數(shù)——commandbehavior, startindex, 與 pagesize。要是你意料得到數(shù)值行數(shù)是101-200,你可以通過(guò)挪用這個(gè)要領(lǐng)設(shè)置startindex為101與pagesize為100而輕易完成這個(gè)功能。
4.數(shù)值毗連(connection)明細(xì)
現(xiàn)在你可以通過(guò)設(shè)置毗連的statisticsenabled屬性為真來(lái)獲取一個(gè)毗連更多的信息。connection對(duì)象提供了兩個(gè)新要領(lǐng)——retrievestatistics 與 resetstatistics。retrievestatistics要領(lǐng)歸回一個(gè)hashtable對(duì)象來(lái)填充毗連信息,如:數(shù)值轉(zhuǎn)移,用戶(hù)明細(xì),游標(biāo)明細(xì),緩存信息與事務(wù)處理。
5.dataset.remoringformat屬性
當(dāng)dataset.remoringformat設(shè)置為二進(jìn)制時(shí), dataset的序列化格式由二進(jìn)制格式代替了原本的xml標(biāo)記格式,這種改變能顯著改善序列化與還原序列化操作的性能。
.NET Framework 3.0 中增加了不少新功能,例如 Windows Workflow Foundation (WF)、Windows Communication Foundation (WCF)、Windows Presentation Foundation (WPF) 和 Windows CardSpace,.NET Framework 3.5 在這些新增功能的基礎(chǔ)上增量構(gòu)建而成。這個(gè)之外,.NET Framework 3.5 還包羅若干技術(shù)領(lǐng)域中的大量新功能,它們以新程序集的形式添加,以制止重大更改。這asp.net 工作流些新功能包孕:
與語(yǔ)言集成查詢(xún) (LINQ) 和數(shù)值感知緊密集成。借助這個(gè)新功能,您可以使用相同的語(yǔ)法,在任何支持 LINQ 的語(yǔ)言中編著相干代碼,以篩選和枚舉多種類(lèi)型的 SQL 數(shù)值、調(diào)集、XML 和數(shù)值集,以及創(chuàng)建它們的投影。
利用 ASP.NET AJAX 可以創(chuàng)建更有效、更具交互性、高度個(gè)性化的 Web 體驗(yàn),這些體驗(yàn)在所有最流行的瀏覽器上都能實(shí)現(xiàn)。
用于生成 WCF 服務(wù)的全新 Web 協(xié)議支持,包孕 AJAX、JSON、REST、POX、RSS、ATOM 和若干新的 WS-* 標(biāo)準(zhǔn)。
Visual Studio 2008 中面向 WF、WCF 和 WPF 的完整工具支持,其中包孕支持工作流的服務(wù)這一新技術(shù)。
.NET Framework 3.5 基類(lèi)庫(kù) (BCL) 中的新類(lèi)可滿(mǎn)足許多常見(jiàn)的客戶(hù)請(qǐng)求。
重要事項(xiàng):
要是安裝有 .NET Framework 3.5 的早期預(yù)發(fā)行版本,則運(yùn)行此安裝之前,必須使用“添加/刪除程序”卸載那一些預(yù)發(fā)行版本。
.NET Framework 3.5 SP1集成了此前發(fā)布的三十個(gè)相關(guān)Hotfix熱修復(fù)補(bǔ)丁,同時(shí)還引入了不少新特性和改進(jìn):
1、ASP.NET動(dòng)態(tài)數(shù)據(jù),它提供了豐富的框架,從而使用戶(hù)可以快速進(jìn)行數(shù)據(jù)驅(qū)動(dòng)的開(kāi)發(fā),而無(wú)需編寫(xiě)代碼;ASP.NET AJA 的一項(xiàng)新增功能,對(duì)管理瀏覽器歷史記錄提供了支持(支持后退按鈕)。有關(guān)更多信息,請(qǐng)參見(jiàn)ASP.NET和Web開(kāi)發(fā)中的新增功能。
2、對(duì)公共語(yǔ)言運(yùn)行時(shí)的核心改進(jìn)包括:改進(jìn)了.NET Framework本機(jī)映像的布局、選擇不再對(duì)完全受信任的程序集進(jìn)行強(qiáng)名稱(chēng)驗(yàn)證、提高了應(yīng)用程序啟動(dòng)性能、改進(jìn)了生成的代碼以縮短端對(duì)端應(yīng)用程序執(zhí)行時(shí)間、選擇在A(yíng)SLR(地址空間布局隨機(jī)化)模式下運(yùn)行托管代碼(如果操作系統(tǒng)支持)。此外,從網(wǎng)絡(luò)共享打開(kāi)的托管應(yīng)用程序在完全受信任環(huán)境下運(yùn)行時(shí)與本機(jī)應(yīng)用程序具有相同的行為。
3、提高了Windows Presentation Foundation的性能,包括縮短了啟動(dòng)時(shí)間,提高了與位圖效果有關(guān)的性能。WPF的其他新增功能包括:改善了對(duì)業(yè)務(wù)線(xiàn)應(yīng)用程序、本機(jī)初始屏幕、DirectX 像素著色器的支持,并且新增了WebBrowser控件。
4、ClickOnce應(yīng)用程序發(fā)行者可以決定在適當(dāng)情況下不進(jìn)行簽名和加密,開(kāi)發(fā)人員可以編程方式安裝ClickOnce應(yīng)用程序以顯示自定義署名,并且ClickOnce錯(cuò)誤對(duì)話(huà)框支持鏈接到Web上應(yīng)用程序特定的支持網(wǎng)站。
5、實(shí)體框架是從現(xiàn)有的一套ADO.NET數(shù)據(jù)訪(fǎng)問(wèn)技術(shù)發(fā)展而來(lái)的。利用實(shí)體框架,開(kāi)發(fā)人員可以按照應(yīng)用程序特定的域模型(而不是基礎(chǔ)數(shù)據(jù)庫(kù)模型)來(lái)針對(duì)關(guān)系數(shù)據(jù)庫(kù)進(jìn)行編程。有關(guān)更多信息,請(qǐng)參見(jiàn)實(shí)體框架入門(mén)。實(shí)體框架還引入了一些其他功能,包括支持SQL Server 2008的新類(lèi)型、默認(rèn)實(shí)體圖形序列化和實(shí)體數(shù)據(jù)源。在此版本中,實(shí)體框架支持SQL Server 2008中的新日期和文件流功能。圖形序列化工作可幫助開(kāi)發(fā)人員生成將全部圖形建模為數(shù)據(jù)協(xié)定的Windows Communication Foundation (WCF)服務(wù)。實(shí)體數(shù)據(jù)源為希望使用實(shí)體框架的ASP.NET應(yīng)用程序構(gòu)建者提供了傳統(tǒng)的數(shù)據(jù)源體驗(yàn)。
6、LINQ to SQL新增了對(duì)SQL Server 2008中的新日期和文件流功能的支持。
7、ADO.NET Data Services Framework由滿(mǎn)足以下條件的模式和庫(kù)組合而成:支持將數(shù)據(jù)公開(kāi)為一項(xiàng)基于REST(具象狀態(tài)傳輸)的靈活數(shù)據(jù)服務(wù),企業(yè)網(wǎng)絡(luò)內(nèi)部或整個(gè)互聯(lián)網(wǎng)上的Web客戶(hù)端都可以使用該服務(wù)。ADO.NET Data Services Framework支持基于任何數(shù)據(jù)源創(chuàng)建數(shù)據(jù)服務(wù)。通過(guò)與 ADO.NET Entity Framework 的充分集成,可以輕松公開(kāi)基礎(chǔ)存儲(chǔ)架構(gòu)的概念視圖模型。可以輕松地從任一平臺(tái)訪(fǎng)問(wèn)使用ADO.NET Data Services Framework創(chuàng)建的服務(wù)以及兼容的Windows Live (dev.live.com)服務(wù)。針對(duì)運(yùn)行在微軟平臺(tái)上的客戶(hù)端應(yīng)用程序提供了一組客戶(hù)端庫(kù),以簡(jiǎn)化與數(shù)據(jù)服務(wù)的交互。例如,基于.NET Framework的客戶(hù)端可以使用LINQ查詢(xún)數(shù)據(jù)服務(wù),也可以使用簡(jiǎn)單的.NET Framework對(duì)象層更新此服務(wù)中的數(shù)據(jù)。
8、現(xiàn)在,Windows Communication Foundation改進(jìn)了對(duì)互操作性的支持,增強(qiáng)了部分受信任情況下的調(diào)試體驗(yàn),并且擴(kuò)展了整合協(xié)議支持以便在Web 2.0應(yīng)用程序中可以進(jìn)行更廣泛的應(yīng)用,從而使DataContract序列化程序變得更易于使用。
9、用于SQL Server(SqlClient) 的.NET Framework數(shù)據(jù)提供程序新增了對(duì)SQL Server 2008中的文件流和稀疏列功能的支持
.NET Framework 3.5 SP1正式版完整安裝包本地下載(231MB):
http://drivers.mydrivers.com/drivers/243-97382-Microsoft-Microsoft.NET-Framework-3.5-SP1/
知識(shí)庫(kù)文章KB951847:
http://support.microsoft.com/kb/951847/en-us
發(fā)行說(shuō)明:
http://download.microsoft.com/download/A/2/8/A2807F78-C861-4B66-9B31-9205C3F22252/dotNet35SP1Readme.htm
c:\windows\system32\mscoree.dll
c:\windows\system32\mscorier.dll
c:\windows\system32\mscories.dll
c:\windows\system32\dfshim.dll
c:\windows\system32\netfxperf.dll
這幾個(gè)文件一定要放在system32下面
C:\windows\system32\mui\0409\mscoreer.dll
C:\windows\system32\mui\0409\mscorees.dll
我們猜想mui下面其他們版本的也是必須的
C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089
c:\windows\assembly\gac_32\[others]
需要其他們的組件也要添加,,比如System.Windows.Forms
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\[others]
這個(gè)文件夾下面只需要mscorjit.dll mscorwks.dll兩個(gè)文件就可以使console運(yùn)作正常。
c:\windows\winsxs\Manifests\...
c:\windows\winsxs\policies\...
c:\windows\winsxs\...
winsxs下有很多重要的組件,版本也很繁雜。確保一個(gè)都不能少。這些文件支撐著mscorwks.dll,沒(méi)有他們,mscorwks也無(wú)法加載。
REG:
HKEY_CLASSES_ROOT\TypeLib\{BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
HKEY_CLASSES_ROOT\TypeLib\{BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}\2.0 = REG_SZ, mscorlib.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\InstallRoot = REG_SZ,C:\WINDOWS\Microsoft.NET\Framework\
只要設(shè)置了安裝位置,jit自己能找到相應(yīng)的framework。有了這些文件,你們就能運(yùn)行.net 2.0的程序了。
]]>我們來(lái)看看以下 ClrInfo.cs 吧:
using System; using System.Text; namespace Skyiv { public class ClrInfo { static void Main() { Console.WriteLine(" OS Version: {0}", Environment.OSVersion); Console.WriteLine(" CLR Version: {0} ( {1} )", Environment.Version, RuntimeFramework.CurrentFramework); Console.WriteLine("Default Encoding: {0}", Encoding.Default); Console.WriteLine(); Console.WriteLine(typeof(string).AssemblyQualifiedName); #if !NetFx20 Console.WriteLine(typeof(System.IO.Packaging.Package).AssemblyQualifiedName); Console.WriteLine(typeof(System.TimeZoneInfo).AssemblyQualifiedName); #endif Console.WriteLine(); Console.WriteLine("Available Frameworks:"); foreach (var frame in RuntimeFramework.AvailableFrameworks) Console.WriteLine(" " + frame); } } } |
使用以下 makefile 文件來(lái)編譯(請(qǐng)參見(jiàn): 淺談 make 工具):
使用 nmake.exe 進(jìn)行編譯(所需的 RuntimeFamework.cs 請(qǐng)參見(jiàn) .NET Framework CLR 版本檢測(cè)):
使用 Sun VirtualBox 全新安裝 Microsoft Windows Server 2003 R2 Enterprise Edition Service Pack 2 操作系統(tǒng):
運(yùn)行 ClrInfo35.exe,結(jié)果如下所示:
運(yùn)行 ClrInfo40.exe,結(jié)果如下所示:
好吧,讓我們安裝 Microsoft .NET Framework 2.0 SP2 吧
]]>1. .Net中的common language runtime (CLR) 是一個(gè)可以被多個(gè)不同語(yǔ)言使用的runtime. 不管使用哪種編譯器,所生成的結(jié)果都是一個(gè)managed module. 一個(gè)managed module是一個(gè)標(biāo)準(zhǔn)的Windows Portable executable (PE) 文件,這個(gè)文件必須由CLR來(lái)執(zhí)行.
一個(gè)managed module的組成:
Part |
Description |
PE Header |
標(biāo)準(zhǔn)的 Windows PE header, 類(lèi)似于Common Object File Format (COFF) header. 這個(gè)header包含了文件類(lèi)型: GUI, CUI, or DLL, 它同樣包含了一個(gè)文件創(chuàng)建時(shí)的時(shí)間戳. 對(duì)只包含IL代碼的的modules,PE header中的大部分信息被忽略. 對(duì)包含native CPU代碼的module,這個(gè)header包含了關(guān)于native CPU代碼的信息. |
CLR Header |
包含了一個(gè)managed module所必須的信息(由CLR和其工具解析) . 這個(gè)header包含了所需的CLR版本和一些狀態(tài)標(biāo)志位, managed module的入口方法(Main方法,一個(gè)MethodDef metadata token), metadata的位置/大小, 資源, strong name, 一些標(biāo)志位和其他信息. |
Metadata |
每個(gè)managed module都包含metadata表. 這些表有兩種類(lèi)型: 定義types和members的的表和定義Referenced的type和members的表. |
Intermediate language (IL) code |
由編譯器編譯的代碼,真正執(zhí)行時(shí)候CLR會(huì)將IL代碼編譯為native CPU instructions. |
2. 一個(gè) assembly是一個(gè)或多個(gè)managed modules/資源文件的邏輯組合, 它是最小的可重用,擁有版本信息和安全信息的單元. PE文件包含一塊叫做manifest的數(shù)據(jù)塊. 一個(gè)manifest是另一個(gè)metadata tables的集合. 這些tables定義了組成一個(gè)assembly的文件, 由這些文件定義的exported types, 跟這個(gè)assembly關(guān)聯(lián)的資源或數(shù)據(jù)文件. 一個(gè)典型的例子: 把一些較少使用的types或資源定義在assembly的一個(gè)獨(dú)立文件中,這個(gè)文件只會(huì)在其中的type或資源被使用的時(shí)候才被加載.
3. 可以通過(guò)查找MSCorEE.dll 文件來(lái)判斷.NET是否被安裝,這個(gè)文件位于%windir%\system32 文件夾中. 但是,一臺(tái)機(jī)器允許同時(shí)安裝幾個(gè)版本的.Net Framewor.可以通過(guò)查看一下注冊(cè)表的鍵值來(lái)判斷當(dāng)前.NET的版本: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy
4. 如何裝載 CLR:
5. 當(dāng)創(chuàng)建一個(gè)EXE assembly, 一個(gè)的6字節(jié)的x86 sub function被嵌入到.text section: JMP _CoreExeMain. 這個(gè)_CoreExeMain函數(shù)從MSCorEE.dll導(dǎo)入, 這個(gè)MSCoreEE.dll (Microsoft Component Object Runtime Execution Engine) 在assembly file’s .idata section定義了引用. 所以當(dāng)assembly像正常程序一樣啟動(dòng)時(shí), MSCoreEE.dll被導(dǎo)入到這個(gè)進(jìn)程的地址空間, 這時(shí)_CorExemain 函數(shù)的地址被獲取,同時(shí)JMP instruction被執(zhí)行. 這個(gè)函數(shù)將初始化CLR并且查找這個(gè)可執(zhí)行assembly’s CLR header的可執(zhí)行入口方法,這個(gè)方法的IL代碼將被編譯為native CPU instructions, 隨后CLR跳轉(zhuǎn)這個(gè)native code, 這時(shí),程序已經(jīng)啟動(dòng).
6. 當(dāng)創(chuàng)建一個(gè)DLL assembly, 一個(gè)類(lèi)似的6字節(jié)長(zhǎng)的x86 stub function被嵌入到.text section: JMP _CorDllMain. _CorDllMain 函數(shù)同樣從MSCorEE.dll中引入, 這個(gè)DLL’s .idata section 中包含MSCorEE.dll的引用定義. 所以, 當(dāng)LoadLibrary 執(zhí)行時(shí), _CorDllMain 被調(diào)用來(lái)初始化CLR并返回給應(yīng)用程序來(lái)繼續(xù)執(zhí)行.
7. 這個(gè)6字節(jié)的stub function僅僅在非Windows XP系統(tǒng)中被添加. 在Windows XP以及以后版本中, OS loader檢查嵌入managed code的文件的PE file header的directory entry 14. (IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR定義在WinNT.h) 如果這個(gè)directory entry存在并且擁有一個(gè)非0值, OS loader忽略這個(gè)文件的導(dǎo)入 (.idata) section并且自動(dòng)裝載MSCorEE.dll到進(jìn)程的地址空間并直接跳轉(zhuǎn)到對(duì)應(yīng)的函數(shù).
8. 最后一個(gè)關(guān)于managed PE文件的注意點(diǎn): 他們總是使用32位PE文件格式, 而不是64位PE文件格式. 在64位系統(tǒng)上, OS loader檢查這個(gè)managed 32位PE文件并知道如何去創(chuàng)建一個(gè)64位地址空間.
9. 至于知識(shí)產(chǎn)權(quán)保護(hù), 對(duì)于所有的編譯位IL的代碼并且IL代碼能被很容易被Disassembler程序reverse, 可以使用一個(gè)第三方提供的obfuscator工具. 這些工具“scramble” managed module’s metadata中所有private symbols的名稱(chēng). 另外,可以把一些代碼編譯為unmanaged DLL并在assembly中調(diào)用它.
10. 所有的高級(jí)語(yǔ)言都只是提供了CLR的一個(gè)功能子集. 但是,IL提供了CLR所有的功能.
11. 如果Assembly中的一個(gè)方法第一次被調(diào)用,它的IL代碼需要被編譯為native CPU代碼, 這部分功能由CLR’s JIT (just-in-time)完成. JIT編譯器在內(nèi)存中保存了native CPU instructions, 所以當(dāng)應(yīng)用程序終止時(shí)候,編譯的代碼都將失效. 另外一個(gè)值得記住的重點(diǎn)是JIT編譯過(guò)程當(dāng)中有一個(gè)專(zhuān)門(mén)的優(yōu)化編譯代碼的過(guò)程.
12. Microsoft .Net framework提供了一個(gè)名為NGen.exe的工具; 這個(gè)工具編譯一個(gè)assembly的全部IL代碼為native CPU代碼并將結(jié)果保存到一個(gè)硬盤(pán)文件.
13. IL是一個(gè)stack-based的語(yǔ)言, 所有的IL instructions會(huì)把operands壓棧,并將結(jié)果彈出. IL沒(méi)有提供操作CPU寄存器的指令.
]]>Kent Sharkey: The Technical Evangelist role is always good for a smile. There aren't too many companies willing to call people that. Basically, our role is to go forth into the community to introduce developers to technologies that aren't shipping yet. We are the advance scouts, if you will, preparing people for changes to come.
RL: In your own words, how would you define the goals and strategy Microsoft is using to merge existing (and future) mobile technology with the larger concept of ".NET"?
KS: Good one. If you think of the overall goal of .NET as helping programs (and people) to communicate better it becomes clearer. Today, and in the past, this has been fairly difficult in the mobile space. People needed to be mobile experts, and used primitive tools to craft apps for Pocket PC or phones. Microsoft is attempting to make this easier for developers, and to enable new forms of applications by doing this.
RL: More specifically, how would you define the .NET Compact Framework and Microsoft's goals in developing it?
KS: The .NET Compact Framework is a lightweight version of the .NET Framework, designed to work well with resource constrained devices. The execution engine and garbage collection has been tightened up, to help with devices where overall memory is still measured in MB. In addition, our support for important standards on the device, such as XML and SOAP support, as well as strong database support with SQL CE are a first in the industry. (well, maybe not the strong database support, but hopefully you're with me) What the .NET Compact Framework is doing is giving developers a set of tools that span devices through servers with a single, consistent programming model.
RL: The .NET Compact Framework and Mobile Internet Toolkit are 2 opposing Microsoft technologies that can be used to develop mobile applications with .NET. Generally speaking, what types of applications do you see as best suited for each of these? What are the key differences between them in terms of development tools, programming techniques, development costs, deployment procedures, and end-user experiences.
KS: I wouldn't say that they were opposing, but complementary. Think of them as the device analogs of Windows Forms (.NET Compact Framework) and Web Forms (MMIT). They both have their place, and optimal usage model. In the case of MMIT, the idea is really reach -- MMIT is great for moving your web applications out to a wide variety of devices, phones, etc. It is a great extension to the ASP.NET model. It's problem is the types of devices it typically targets -- cell phones. They typically have poor data entry capabilities. As such, I would say that MMIT is best for apps that don't require a good deal of data entry, and where the amount of data displayed is relatively small (again, due to phone limitations). Finally, MMIT is best suited for always online applications. .NET Compact Framework, on the other hand, brings a few neat items to the table. First up, through either the larger memory on the device and/or SQL CE, it has data storage capabilities. Therefore, .NET Compact Framework is great for applications that spend part of 'their life' disconnected. SQL CE replication allows you to merge your data back into SQL Server as needed (when connected). Second, .NET Compact Framework gives you the richer capabilities of the device UI. You can use controls such as TreeView, ListView and (soon), DataGrid in your applications without having to struggle with a cross platform DHTML solution. The application could also be faster, as no return time is required to retrieve data. Finally, the development model of .NET Compact Framework is just the same as that of desktop Windows Forms, allowing a developer to move freely and easily between developing for the device and the desktop. MMIT has a somewhat different programming model, possibly confusing some.
RL: As a "Technical Evangelist" you recruit developers to use emerging technology. When doing this, who is your target audience? In other words, what types of organizations do you see as being the best candidates for quickly adopting the .NET Compact Framework? Who do you predict will be (or currently are) the early adopters of this technology?
KS: I look at the target audience as being in two main groups. First, there are those groups doing device development today. .NET Compact Framework gives this group a rich set of tools and consistency with the desktop that will help their move forward. Second, there are those who have never done device development. This is the very exciting group, as .NET Compact Framework means that they can now extend their existing applications to the device easily. They no longer have to learn a new programming environment, with new tools and languages.
RL: Through your interactions with the developer community, what have you found to be the most compelling reasons given for adopting the .NET Compact Framework? Conversely, what reasons have been given for NOT adopting the technology?
KS: The most compelling reason for me is that it uses the same tool and programming model as you develop on the desktop. The consistency between .NET and the .NET Compact Framework means that you already know how to do most things on the device. You build both in Visual Studio .NET. As for reasons for NOT adopting the technology, well, I'm just the wrong person to ask that. There isn't any.
More seriously, some of the companies I've spoken with have decided not to move to .NET Compact Framework because they are already working with (and happy with) Embedded Visual C++ or Embedded Visual Basic. Particularly for small developer shops, that have already scaled the learning curve to get their code on the device 'the hard way', the added training time does not make economic sense.
RL: What advice can offer for developers who have already created and deployed applications for the Windows CE platform using Embedded Visual Basic and/or Embedded Visual C++? What factors should be considered when deciding between maintaining existing code or rewriting applications with the .NET Compact Framework?
KS: The answer is easier for the Embedded Visual Basic people, so I'll start there.
Many of the eVB customers that I've spoken to have been happy with the product. Others, however, feel that there is a 'glass ceiling' to the product. If you try to do applications that go beyond this barrier, it becomes quite difficult. In addition, the fact that it was limited to VBScript was quite limiting. For these developers, we have only good news. Now, they have the full VB .NET language, with the Compact Framework of classes to create their applications with.
Embedded Visual C++ developers, on the other hand do have a choice to make. If they need absolute control of the device, and they're happy developing with eVC, I often encourage them to continue. Those that want to create Web Services, or otherwise take advantage of the functionality available with the .NET Compact Framework, however, should do more than look at .NET Compact Framework. They will find that C# is an amazingly easy language to learn, and the framework does make doing a lot of stuff very easy.
<!-- FIN ARTICLE -->
]]>