不少開發人員在.NET剛推出時，經歷一段震撼教育，學習全新的開發模式，一連串的.NET修練研討會也看得出微軟的用心。5月27日新上市的Visual Studio .NET 2003，將保障企業既有的投資，強調單一程式撰寫模式、單一開發工具及單一技術學習的策略，希望降低開發人員的學習曲線，將心力專注於企業與客戶的需求。
Visual Studio .NET 2003新增支援智慧型行動裝置、IPv6通訊協定及Web Services的WSE（Web Services Enhancements）標準，並提升執行效能與安全性。.NET Framework 1.1與.NET Framework 1.0的應用程式可相容並存，Visual C++ .NET新增Windows Form設計工具，大幅增加開發的便利性，而新增的Visual Studio J# .NET，可轉換Java程式至.NET。
.NET Compact Frameworkv實現行動化的理想
增強支援標準化
Visual Studio .NET 2003結合.NET Compact Framework，讓開發人員運用既有的技術和經驗，以統一的程式撰寫模式，開發Windows、Web與智慧型行動裝置應用程式。.NET Compact Framework是.NET Framework的子集合，由於行動裝置容納不下.NET Framework龐大的類別庫，因此.NET Compact Framework中的CLR（Common Language Runtime；通用語言執行環境）移除支援滑鼠和列印等不必要的功能，並加入InputPanel及紅外線等類別，支援觸控筆及無線傳輸等特有的功能。.NET Compact Framework所有類別庫，和.NET Framework有相同的命名和使用原則，開發人員可使用與桌面或伺服器應用程式一樣的撰寫經驗，開發智慧型行動裝置應用程式。
目前.NET Compact Framework僅支援C#和Visual Basic .NET，包含測試與偵錯智慧型行動裝置的模擬服務，開發人員不需裝置實際的硬體設備，即可享有真實的開發經驗。模擬器（Emulator）可模擬任何Windows CE .NET作業系統的裝置，由於提供真實晶片層級的模擬，所以執行模擬器的效率較差。
ASP.NET是以伺服器為基礎的開發平臺，開發人員部署應用程式至Web伺服器，用戶端只要透過瀏覽器連線，即可執行應用程式。Visual Studio .NET 2003的ASP.NET已內建MMIT（Microsoft Mobile Internet Toolkit）行動控制項，可針對行動電話或PDA撰寫程式，使Web的應用更為廣泛。目前行動控制項支援超過200種以上行動裝置，未來會持續推出各類控制項以滿足各式新款手機的需求。對於Smartphone以外的手機，使用ASP.NET行動控制項即可滿足需求。
為確保各家開發的Web Services，可以互通並確保安全性，由微軟、IBM、惠普、英特爾及Oracle等多家公司共同組成的WS-I（Web Services Interoperability Organization；網路服務相容組織），著手擬訂企業使用的Web Services標準方法，使Web Services更具一致性及標準化。最新通過的WSE標準（Web Services Enhancements）包括：WS-Security、WS-Routing、WS-Attachments及DIME（Direct Internet Message Encapsulation）。
WS-Security是SOAP訊息的數位簽章和加密的標準；WS-Routing是SOAP路由的規格；WS-Attachments則是SOAP附加檔案的方法。過去Web Services沒有標準化的規格時，使用Web Services互通資料的雙方，必須先協調定義Web Services交易語意，各家Web Services可能都有不同的規格，這樣就失去Web Services跨企業、跨平臺及跨程式語言的意義。有了公開的標準之後，大家便可遵循相同的規格，達到透通使用的方便性，有助於Web Services的推廣。
為支援WSE標準，Visual Studio .NET 2003推出Web Services Enhancements Kit，不但開發人員可使用WS-Security規格所定義的機制，加密SOAP訊息，確保Web Services的安全性。以往在Web Services附加文件沒有固定的方法，通常是將文件轉成文字檔包在SOAP裡，對方接收SOAP之後，再還原成二進位元碼（Binary Code）。遵循WS-Attachments規格，便提供標準的方法，也提升執行效能。
為解決IPv4面臨的位址耗盡、安全性、自動組態及擴充性等問題，便有了新一代IPv6通訊協定的產生。Visual Studio .NET 2003全新支援IPv6，IP位址由32位元增加為128位元，可提供更優質的定址能力、路由效能及安全性機制。
中介碼讓應用程式跨平臺
Visual J# .NET是.NET的新成員
.NET所有的程式語言在編譯時，都將程式碼編譯成MSIL（Microsoft Intermediate Language；中介語言），也就是IL-Code，真正執行時才轉成機器碼。Java程式也是一樣的原理，將程式碼編譯成P-Code（Pseudo-Code；虛擬碼），.NET的IL-Code和Java的P-Code都是中介碼。中介碼的缺點是會影響執行效能，優點除可跨平臺之外，還可依程式語言的特性，撰寫適合的功能，例如以Visual C# .NET撰寫程式核心部分，以Visual Basic .NET撰寫前端資料展現的部分。
微軟針對Java開發人員移植至.NET環境的JUMP(Java User Migration Path)策略，除原有的JLCA（Java Language Conversion Assistant）之外，Visual Studio .NET 2003新增Visual J# .NET語言。原Visual J++及使用Java語言的開發人員，可將程式碼轉換到Visual J# .NET，既可使用原有的Java技術，更提升開發及使用Web Services的便利性，使用Java JDK 1.1.4類別庫的Java中介碼和Visual J++ 6.0的程式碼，轉換至Visual J# .NET將可完全相容。
在Visual J#推出之前，可使用JLCA將程式碼轉為Visual C# .NET。Visual C# .NET與Visual J# .NET兩者非常類似，差別在於Visual J# .NET是Java語言的.NET工具，而Visual C# .NET是類似C、C++與Java的新語言。Java程式碼要轉換為C#還是J#，取決於開發人員希望繼續使用的Java語言，或學習新語言。
升級的彈性
.NET專屬的傳輸方式：.NET Remoting
惡名昭彰的DLL Hell已不存在
開發工具不斷的推陳出新，資訊人員最關心的仍是原有程式能否升級與相容性的問題。以Visual Basic而言，Visual Studio .NET 2002在專業版以上提供升級工具，Visual Studio .NET 2003標準版即提供升級工具，並加強支援User Control及Web Classes。Visual Basic 6.0可直接升級到Visual Basic .NET，Visual Basic 6.0以前的版本，需先升級到6.0，才能升級到.NET。
.NET Framework 1.0與.NET Framework 1.1的應用程式可以並存，原Visual Studio .NET 2002開發的應用程式預設以.NET Framework 1.0執行，開發人員可選擇以.NET Framework 1.1建置，或針對新增的技術例如支援IPv6，僅升級部分的元件，減少總體升級的負擔。
.NET Framework 1.1比.NET Framework 1.0的安全性預設值控管更為嚴謹，所以Visual Studio .NET 2002的應用程式若沒有仔細設定預設值，以.NET Framework 1.1執行時會有問題。
過去以COM+透過UDP（User Datagram Protocol）不固定傳輸埠的通訊方式，使得COM物件僅能應用於企業內部網路，無法跨越防火牆。.NET Remoting是微軟針對.NET分散式應用程式設計的專屬傳輸方式，因此伺服器必須是微軟的平臺，有別於COM+動態變動傳輸埠，.NET Remoting可讓開發人員彈性選擇傳輸埠，並自行決定Binary或ASCII等編碼方式或傳輸物件，以增加傳輸效率。
.NET Remoting適合即時性應用系統，可提供即時又快速的資料傳輸。以Web Services一定的規範公開的標準傳輸資料，可以實現跨平臺、跨語言及跨網際網路的整合目的，但是封包比較大。在.NET Framework上執行的應用程式，選擇雙向連結性強的.NET Remoting作為機制，可提升系統執行及管理效率。
微軟為保障企業既有的投資，讓COM物件在.NET環境下，可作網際路的應用，.NET 2003可將COM物件轉成SOAP，便可以.NET Remoting連結的技術作穿越火牆的運用，但不代表此可解讀的SOAP文字檔等於Web Services，因為若SOAP裡面包含專屬的命名規則，其他的應用程式不見得可以解析。
過去使用DLL（Dynamic Linking Library；動態連結檔）主要是因為動態連結及資源共享的優點，當多個應用程式使用相同模組時，透過共享的方式，只要保有一份DLL元件，所有Windows環境下的應用程式，都可使用DLL元件提供的函數，不但節省磁碟空間也可節省記憶體空間。
開發人員必須以regsvr32.exe程式註冊DLL元件，因應新應用程式的需求更新DLL元件時，若考慮不周詳未發覺新版元件與其他舊程式不相容，導致新的應用程式使用新版元件正常，但其他呼叫相同元件的應用程式無法運作，這就是DLL Hell惡名昭彰之處。
由於硬體不斷的推陳出新，已不需要太在意資源浪費的問題，.NET在部署元件上也調整設計理念，編輯器在產生執行碼時，同時產生具自我描述能力的Assembly檔，其中包含應用程式的Metadata。開發人員以Xcopy的部署方式，只要將DLL元件及程式複製到資料夾，不需登錄資料庫（Registry），便不再有DLL Hell的問題。
應用程式共享元件仍有其必要性，.NET新增side-by-side開發模式，開發人員仍可將元件註冊到gacutil（Global Access Cache Utility；公域組件快取），透過SN（Strong Name；強式名稱）以內部命名系統，讓同一DLL元件的多種版本可同時存在，即可避免DLL Hell的陷阱。
除了Xcopy的部署方式，為解決用戶端應用程式發展受限的問題，Visual Studio .NET 2003另提供非接觸式（No-touch）部署，Windows Form應用程式可透過網路下載。
首次部署或更新應用程式時，在瀏覽器輸入網址，即可下載應用程式，不是一次下載所有的應用程式，僅傳送需要使用的功能。由於No-touch部署應用程式結合網際網路，連結到指定網址即提供執行檔連結，不再需要製作安裝光碟，逐臺安裝應用程式，且執行效能較Web應用程式佳。.NET與Java是相互競爭還是各取所需？
在.NET與Java兩大陣營互相叫囂的同時，仔細分析雙方的強項，其實各有各的優點，由於訴求不同，所針對的企業類型其實有所區隔。雙方在技術方面互相學習，.NET的CLR學自Java JVM（Java Virtual Machine）的概念，Java的JSP參考微軟ASP的設計，最後的漁翁得利者應該是企業及開發人員。
CLR與JVM的對決
微軟的.NET與昇陽的Java針對跨平臺的特性，事實上是「一個跨平臺，各自表述」的情況。目前.NET的跨平臺其實是跨所有桌上型電腦、筆記型電腦、平板電腦（Tablet PC）、PDA及Smartphone等Windows系列作業系統的平臺；Java則是跨作業系統及處理器的平臺。.NET為達到跨行動裝置的理想，終於在.NET Framework 1.1推出.NET Compact Framework，就是針對行動裝置設計的精簡型程式集，開發人員不需學習新的技術，以既有專長及經驗即可開發各種裝置上的應用程式。
微軟.NET產品行銷經理麥超俊表示：「技術上.NET是可以跨平臺的。」對於.NET目前的策略將先專注於既有的Windows作業系統，並公開.NET Framework及CLR的程式碼和規格於ISO及ECMA等公正的單位，供各家廠商實作各種處理器及作業系統的.NET版本。著名的Mono專案即將.NET的C#編譯器、CLR及類別庫，實作在Linux作業系統上。
由於.NET是針對Intel處理器及Windows作業系統最佳化的平臺，所以執行效能相對比Java好，Java為兼顧跨平臺的獨立性，不能依據各種作業系統的特性最佳化勢必犧牲效能。昇陽為改善效能問題，已進一步針對不同處理器設計最佳化的JVM，並持續改善JIT（Just In Time）。
昇陽教育訓練服務總經理洪志鵬說：「GUI是跨平臺效能最大的包袱。」由於J2EE沒有GUI（Graphic User Interfaces；圖形使用者介面）的問題，所以效能較佳。目前甚至有aJile等廠商設計販賣機之類專屬系統的JVM硬體晶片，使用者可透過手機扣點數的方式購買飲料。
誰令企業更有安全感
.NET 的CLR帶來許多好處，除了記憶管理、資源回收、執行緒處理及網路能力之外，更可保障應用程式的安全性。為防止應用程式因檔案損毀或中毒而無法正確執行，例如檔案被木馬程式病毒刪除，或被有心人士更換成相同檔名卻不同作用的檔案。Windows Form提供SN（Strong Name；強式名稱）的機制，開發人員先產生一組金鑰檔案，建置應用程式時加入金鑰檔案，再以gacutil（Global Assembly Cache Utility；公域組件快取）將金鑰檔案存放在快取記憶體內，應用程式執行時便會自動檢查金鑰是否正確，若不正確便拒絕執行。Java跨平臺的特性雖造成效能的瓶項，卻也帶來安全性的保障，所有未經認證的Java程式只能在限定的記憶體區塊執行，不會影響系統本身。
Java與.NET可能手牽手嗎？
微軟與昇陽雙方均表示不會主動支援對方的平臺，不過仍有其他資訊廠商致力於元件的互通。雖然沒有直接元件的互通，.NET仍在Visual J# .NET及Visual C# .NET中提供轉換Java程式的機制。若是JDK 1.1.4以前的Java P-Code（Pseudo code；虛擬碼），可直接透過Visual J# Binary Converter Tool的JbImp.exe程式，轉換成.NET的MSIL（Microsoft Intermediate Language；中介碼）。
由於J#與C#都是類似Java的程式語言，昇陽表示只要使用文書編輯器的字串取代功能，即可將J#與C#程式碼轉換成Java程式。.NET與Java都是很好的架構，應視情況選擇。微軟.NET產品行銷經理麥超俊表示：「.NET提供單一技術學習的開發環境，只要學會一種.NET程式語言，即可開發各種裝置的應用程式。」在.NET真正跨平臺之前，如果企業全面使用的是微軟平臺，那麼採用.NET開發應用程式，無疑是最明智的抉擇，開發人員不用針對各種裝置學習不同的開發技巧，可降低學習成本也保有最佳化的效能。若有異質性系統跨平臺的需求則Java是必然的選擇，在詬病Java的效能之前，應先了解Java在跨平臺上所作的努力。文⊙李延華
