क्या .NET विंडोज़ एप्लिकेशन को एक .exe में संपीड़ित किया जा सकता है?

Question

मैं .NET डेस्कटॉप अनुप्रयोगों से बहुत परिचित नहीं हूं (Visual Studio 2005 का उपयोग कर)। क्या पूरे एप्लिकेशन को एक .exe फ़ाइल से चलाना संभव है?

Answer 1

हां, आप ILMerge उपकरण का उपयोग कर सकते हैं।

Answer 2

.NET Reactor नामक एक तृतीय पक्ष टूल है जो आपके लिए यह कर सकता है। मैंने टूल का उपयोग नहीं किया है और इसलिए मुझे यकीन नहीं है कि यह कितना अच्छा काम करता है।

Answer 3

आपको इसे कई असेंबली में विभाजित नहीं करना चाहिए (जो आमतौर पर विजुअल स्टूडियो समाधान के अंदर प्रोजेक्ट होते हैं)। वैसे भी .NET Framework की आवश्यकता है, इसका कोई तरीका नहीं है - और यह सही तरीका है - इसे एम्बेड करने के लिए।

Answer 4

जैसा कि कहा गया है, आप ILMerge का उपयोग कर सकते हैं।

यदि आप the free Phoenix protector का उपयोग करते हैं, तो यह आसान हो सकता है, जो आपके कोड की सुरक्षा भी करता है।

Answer 5

मैंने EXE और DLL फ़ाइलों को एकल EXE फ़ाइल में पैक करने के लिए .NETZ .NET ओपन सोर्स निष्पादन योग्य पैकर का उपयोग किया है। यहाँ कैसे एक फ़ाइल में DLL फ़ाइलों पैक करने के लिए के लिए एक कमांड लाइन उदाहरण है:

netz -s application.exe foo.dll bar.dll 

Answer 6

हां। .NET में आप अपने पूरे एप्लिकेशन को एक EXE फ़ाइल के रूप में encapsulated कर सकते हैं। बस सुनिश्चित करें कि आपके समाधान में केवल एक विंडोज़ एप्लिकेशन प्रोजेक्ट है (और सेटअप के अलावा अन्य कोई परियोजना नहीं है)।

EXE अपने नेट परियोजना द्वारा बनाई गई फ़ाइल एक स्टैंड-अलोन निष्पादन योग्य फ़ाइल नहीं होगा, लेकिन केवल निर्भरता यह होगा .NET रनटाइम हो जाएगा (जब तक आप अन्य DLL विधानसभाओं के संदर्भ जोड़)। यदि आप .NET 2.0 (जो मैं अनुशंसा करता हूं) का उपयोग करता हूं, तो रनटाइम नए पीसी पर प्रीइंस्टॉल किया जाता है और पुरानी मशीनों पर स्थापित करने के लिए बहुत आसान और त्वरित है (इंस्टॉलर लगभग 23 एमबी है)।

यदि आपके ऐप को अन्य असेंबली (जैसे डेटा एक्सेस डीएलएल या .NET क्लास लाइब्रेरी डीएलएल प्रोजेक्ट) का संदर्भ देने की आवश्यकता है, तो आप अपने एक्सईई और सभी संदर्भित डीएलएल को गठबंधन करने के लिए यहां अन्य पोस्टर द्वारा संदर्भित टूल्स का उपयोग कर सकते हैं एक एकल EXE फ़ाइल। हालांकि, पारंपरिक अभ्यास किसी भी निर्भर डीएलएल के साथ अलग फ़ाइलों के रूप में बस EXE फ़ाइल को तैनात करने का निर्देश देगा। .NET में, निर्भर डीएलएल की तैनाती बहुत सरल है: बस उन्हें क्लाइंट मशीन पर EXE फ़ाइल के समान फ़ोल्डर में रखें, और आप कर चुके हैं।

एक एकल फ़ाइल इंस्टॉलर (या तो setup.EXE या setup.MSI) के रूप में अपने एप्लिकेशन को तैनात करना (चाहे एक फ़ाइल या कई) है। .NET परिनियोजन प्रोजेक्ट टेम्पलेट्स के साथ आता है जो आपके लिए इंस्टॉलर बना सकता है।

थोड़ा ऑफ-विषय: आप अपने .NET अनुप्रयोग को देशी EXE के रूप में संकलित करने के लिए एनजीएनएन का उपयोग कर सकते हैं, लेकिन यह अभी भी .NET रनटाइम पर निर्भर होगा। देशी संकलन का लाभ यह है कि कुछ चीजों को पहले से संकलित किया जा सकता है, लेकिन मैंने कभी ऐसी स्थिति नहीं देखी है जहां यह छोटा प्रदर्शन वृद्धि परेशान करने योग्य है।

Answer 7

हां, आप एक एकल EXE फ़ाइल बना सकते हैं।दो अच्छे लेख हैं:

1. How to include all related DLLs into a single EXE file
2. .NET runtime -- single EXE file

Answer 8

आप NBox उपयोगिता की कोशिश कर सकते हैं।

Answer 9

ILMerge एक ही विधानसभा के लिए विधानसभाओं गठजोड़ कर सकते हैं प्रदान की विधानसभा केवल कोड कामयाब रहा है। आप कमांडलाइन एप्लिकेशन का उपयोग कर सकते हैं, या EXE फ़ाइल के संदर्भ जोड़ सकते हैं और प्रोग्रामेटिक रूप से मर्ज कर सकते हैं। एक जीयूआई संस्करण के लिए, Eazfuscator है, और .Netz भी हैं, जिनमें से दोनों निःशुल्क हैं। भुगतान किए गए अनुप्रयोगों में BoxedApp और SmartAssembly शामिल हैं।

यदि आपको अप्रबंधित कोड के साथ असेंबली मर्ज करना है, तो मैं SmartAssembly का सुझाव दूंगा। मैंने SmartAssembly के साथ कभी भी हिचकी नहीं की, लेकिन अन्य सभी के साथ। यहां, यह आवश्यक निर्भरताओं को आपकी मुख्य EXE फ़ाइल में संसाधनों के रूप में एम्बेड कर सकता है।

आप यह सब मैन्युअल रूप से नहीं या चिंता करने की अगर एक विधानसभा प्रबंधित किया जाता है की आवश्यकता होगी, अपने संसाधनों में DLL फ़ाइल एम्बेड करने और फिर AppDomain के विधानसभा ResolveHandler पर निर्भर द्वारा मिश्रित मोड में कर सकते हैं। यह सबसे खराब मामला अपनाने वाला एक-स्टॉप समाधान है, यानी, अप्रबंधित कोड के साथ असेंबली।

class Program 
{ 
    [STAThread] 
    static void Main() 
    { 
     AppDomain.CurrentDomain.AssemblyResolve += (sender, args) => 
     { 
      string assemblyName = new AssemblyName(args.Name).Name; 
      if (assemblyName.EndsWith(".resources")) 
       return null; 

      string dllName = assemblyName + ".dll"; 
      string dllFullPath = Path.Combine(GetMyApplicationSpecificPath(), dllName); 

      using (Stream s = Assembly.GetEntryAssembly().GetManifestResourceStream(typeof(Program).Namespace + ".Resources." + dllName)) 
      { 
       byte[] data = new byte[stream.Length]; 
       s.Read(data, 0, data.Length); 

       // Or just byte[] data = new BinaryReader(s).ReadBytes((int)s.Length); 

       File.WriteAllBytes(dllFullPath, data); 
      } 

      return Assembly.LoadFrom(dllFullPath); 
     }; 
    } 
} 

जहां Program कक्षा का नाम है। यहां कुंजी बाइट्स को फ़ाइल में लिखना और उसके स्थान से लोड करना है। चिकन-एंड-अंडे की समस्या से बचने के लिए, आपको यह सुनिश्चित करना होगा कि आप असेंबली तक पहुंचने से पहले हैंडलर घोषित करें और लोडिंग (असेंबली हल करने) के अंदर आप असेंबली सदस्यों (या असेंबली से निपटने के लिए कुछ भी तत्काल) तक पहुंच नहीं पाते हैं। अंश। यह भी सुनिश्चित करने के लिए सावधानी बरतें कि GetMyApplicationSpecificPath() कोई अस्थायी निर्देशिका नहीं है क्योंकि अस्थायी फ़ाइलों को अन्य प्रोग्रामों द्वारा या स्वयं द्वारा मिटाए जाने का प्रयास किया जा सकता है (यह नहीं कि आपका प्रोग्राम डीएलएल फ़ाइल तक पहुंचने पर हटा दिया जाएगा, लेकिन कम से कम यह एक उपद्रव है। AppData एक अच्छा स्थान है)। यह भी ध्यान रखें कि आपको हर बार बाइट लिखना होगा; आप स्थान से लोड नहीं कर सकते हैं क्योंकि डीएलएल फ़ाइल पहले से ही वहां रहती है।

प्रबंधित DLL फ़ाइलों के लिए, आपको बाइट्स लिखने की आवश्यकता नहीं है, लेकिन सीधे DLL फ़ाइल के स्थान से लोड करें, या केवल बाइट्स पढ़ें और असेंबली को स्मृति से लोड करें। इस या तो जैसा:

using (Stream s = Assembly.GetEntryAssembly().GetManifestResourceStream(typeof(Program).Namespace + ".Resources." + dllName)) 
{ 
    byte[] data = new byte[stream.Length]; 
    s.Read(data, 0, data.Length); 
    return Assembly.Load(data); 
} 

// Or just 

return Assembly.LoadFrom(dllFullPath); // If location is known. 

तो विधानसभा पूरी तरह से अप्रबंधित है, तो आप this link या this कैसे ऐसी DLL फ़ाइलों को लोड करने के लिए के रूप में देख सकते हैं।

Answer 10

मैं अपने आप को .netshrink का उपयोग कर रहा हूं, और यह वही है जो आपको चाहिए। यह मुख्य और अतिरिक्त असेंबली (डीएलएल फाइल) को एक निष्पादन योग्य छवि में पैक करता है।

मैं इसे पहले से ही एक वर्ष के लिए उपयोग कर रहा हूं, और मैं आईएलएमर्ज पर वापस नहीं जा रहा हूं (यह हमेशा किसी बिंदु पर दुर्घटनाग्रस्त हो जाता है ...)।

Answer 11

Jeffrey Richter उसकी book excerpt में लिखा है कि application domain’s ResolveAssembly घटना के साथ एक कॉलबैक विधि कार्यक्रम प्रारंभ दौरान तीसरे पक्ष के विधानसभाओं और DLL फ़ाइलों को ढूंढना CLR सक्षम करने के लिए पंजीकृत किया जा सकता:

AppDomain.CurrentDomain.AssemblyResolve += (sender, 
    args) => { 
    String resourceName = "AssemblyLoadingAndReflection." + 
    new AssemblyName(args.Name).Name + ".dll"; 
    using (var stream =  
     Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName)){ 
     Byte[] assemblyData = new Byte[stream.Length]; 
     stream.Read(assemblyData, 0, assemblyData.Length); 
     return Assembly.Load(assemblyData); 
     } 
    }; 

अस्वीकरण: मैंने इसे स्वयं नहीं उपयोग किया है। जहां तक ​​मुझे समझा गया, क्लाइंट को अभी भी .NET फ्रेमवर्क स्थापित करने की आवश्यकता है।

Answer 12

आज, 2015 में, आप इसके लिए Costura.Fody का उपयोग कर सकते हैं। इसका उपयोग करने से आपकी परियोजना में NuGet पैकेज जोड़ने और पुन: सम्मिलित करने की मात्रा है। मुझे यकीन नहीं है कि यह दृश्य में   स्टूडियो   2005 के साथ काम करता है, लेकिन फिर यह वर्ष 2008 भी नहीं है। मैंने इसे अपनी कुछ परियोजनाओं में उपयोग किया है और यह बहुत अच्छा काम करता है।

Fody एक सामान्य उद्देश्य Code Weaver है जो मुफ़्त और खुला स्रोत है। बुनियादी विचार यह है कि यह संकलित .NET कोड की पोस्ट-प्रोसेसिंग को सुविधाओं के साथ बढ़ाने के लिए अनुमति देता है। उदाहरण के लिए, प्रत्येक विधि कॉल, आदि में लॉगिंग जोड़ा जा सकता है। हमारे मामले में, यह निर्भर डीएलएल फ़ाइलों को असेंबली संसाधनों में पैकेजिंग कर रहा है, ताकि वे प्रोग्राम रनटाइम के दौरान लोड हो सकें जैसे कि वे स्टैंड-अलोन निर्भरताएं हों।