2011-05-23 8 views
9

उपग्रह असेंबली के लक्ष्य ढांचे संस्करण का क्या निर्णय लेता है?उपग्रह असेंबली के लक्ष्य ढांचे संस्करण का क्या निर्णय लेता है?

लॉग फ़ाइल को देखकर मैं देख सकता हूं कि उपग्रह असेंबली ResGen.exe और Al.exe चलाकर बनाई गई है लेकिन मुझे यह नहीं पता कि परिणामस्वरूप असेंबली के लक्ष्य ढांचे का क्या निर्णय लेता है।

पृष्ठभूमि

मैं एक समस्या है, जहां एक उपग्रह विधानसभा .NET 4.0 क्रम निर्माण सर्वर पर जब मैं इसे बनाने के लिए लक्षित लेकिन जब मैं यह संकलन .NET 2.0 क्रम के लिए लक्षित हो जाता है को हल करने की कोशिश कर रहा हूँ मेरे विकास कंप्यूटर पर। शेष समाधान .NET 2.0 रनटाइम के लिए लक्षित है और निष्पादन योग्य उपग्रह असेंबली लोड नहीं करेगा अगर इसे .NET 4.0 रनटाइम के लिए लक्षित किया गया है।

मैंने बिल्ड सर्वर पर msbuild का उपयोग करके "मैन्युअल रूप से" प्रोजेक्ट बनाने का प्रयास किया है जिसके परिणामस्वरूप .NET 2.0 रनटाइम के लिए लक्षित उपग्रह असेंबली भी होती है।

जब मैं स्वचालित बिल्ड सर्वर का उपयोग करता हूं तो मुझे केवल 4.0 का गलत लक्ष्य रनटाइम संस्करण मिलता है।

उत्तर

15

मैंने पूरे दिन इसे ट्रैक करने में बिताया, लेकिन मुझे लगता है कि मैंने इसे हल किया है। हाँ, मैं एक शहीद हूँ। दुर्भाग्यपूर्ण साहस के निष्कर्षों से लाभ!

मेरा सबसे अच्छा अनुमान यह है कि विंडोज 7.1 एसडीके स्थापना में रजिस्ट्री कुंजियों के संबंध में इसमें एक बग है। कुछ रजिस्ट्री मान 7.0a पर इंगित करते हैं जब इसे 7.1 पर इंगित करना चाहिए। इसके अतिरिक्त, कुछ रजिस्ट्री कुंजियों का गलत नाम दिया गया है।

कुछ मैन्युअल परिवर्तनों के बाद, मेरे संसाधन डीएलएल ढांचे के उपयुक्त लक्ष्य संस्करण को संकलित करने के लिए वापस आ गए थे। मुझे पूरा यकीन है कि एक x64 संस्करण नहीं मेरे परिवर्तनों के साथ पैच किया जाएगा। अपने जोखिम पर प्रयोग करें!

मैं व्यक्तिगत रूप से हमारे निर्माण सर्वर के लिए हैक अप रजिस्ट्री रखने से बहुत खुश नहीं हूं। कौन जानता है कि मेरे सर्वर पर रनटाइम पर अन्य भय मुझे क्या इंतजार कर रही हैं। मैं सिर्फ विजुअल स्टूडियो 2010 को स्थापित करने पर विचार कर रहा हूं।

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools] 
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\bin\\" 
"ProductVersion"="7.1.7600.0.30514" 
"ComponentName"="Microsoft Windows SDK NetFx 3.5 Tools" 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools\1033] 
"SP"=dword:00000000 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86] 
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\bin\\" 
"ProductVersion"="7.1.7600.0.30514" 
"ComponentName"="Microsoft Windows SDK NetFx 3.5 Tools" 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86\1033] 
"SP"=dword:00000000 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0] 
"MSBuildToolsPath"="c:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\" 
"MSBuildToolsRoot"="c:\\WINDOWS\\Microsoft.NET\\Framework\\" 
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])" 
"MSBuildRuntimeVersion"="4.0.30319" 
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\[email protected])" 
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\[email protected])" 
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\[email protected])" 
+0

आपके कामकाज ने मेरे लिए काम किया। वहाँ एक समान अधिकारी [वैकल्पिक हल] (http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3 है -5-जेनरेट-गलत-एम्बेडेड-संसाधन) माइक्रोसॉफ्ट कनेक्ट पर पोस्ट किया गया। इसमें एमएसबिल्ड के लिए v7.0A v7.1 में परिवर्तन शामिल नहीं हैं। मेरे निर्माण मशीन पर काम करने के लिए उन बदलावों को जरूरी था। आपका बहुत बहुत धन्यवाद! –

+0

मैं पुष्टि कर सकता हूं कि इस मुद्दे को हल करता है (या कम से कम मेरे लिए किया गया है)। कुछ कारणों से आखिरी संपादन के अलावा - HKEY_LOCAL_MACHINE \ सॉफ़्टवेयर \ माइक्रोसॉफ्ट \ MSBuild \ ToolsVersions \ 4.0 - पहले से ही किया गया था इसलिए मुझे बस बाकी और बूम खत्म करना पड़ा, मेरे सभी सैटेलाइट असेंबली अब मेरे ऐप के साथ अच्छा खेलते हैं। – CLR

+1

एक आकर्षण की तरह काम किया। मुझे अपने सिस्टम पर Wow3264Node के लिए एक ही नियम जोड़ना पड़ा, लेकिन उसके बाद मेरे निर्माण ने सही ढांचे को फिर से लक्षित किया। – Jensen

0

स्वचालित निर्माण कैसे कमांड वातावरण स्थापित करता है जहां एमएसबिल्ड निष्पादित किया जाता है? यदि आप इसे समझ सकते हैं, और देखें कि जब आप "मैन्युअल रूप से" एक ही मशीन पर सफल निर्माण करते हैं तो आप कमांड वातावरण को कैसे सेट अप करते हैं, तो आपको यह जवाब मिल जाएगा। यदि आप इन सुरागों को नहीं ढूंढ पा रहे हैं, तो डायग्नोस्टिक्स (/ fl /flp:v=diag ;logfile=build-diag.log) के साथ लॉग इन करने के लिए बिल्ड सेट करें और ऑटो बनाम मैन्युअल बिल्ड लॉग को अलग करें।

1

आज भी एक ही समस्या में भाग लें। ऐसा लगता है कि कुछ आवश्यक पर्यावरण चर सेट नहीं किए गए थे।

इससे पहले, अपने निर्माण सर्वर पर निर्माण आदेश बस गया था "C: \ Windows \ Microsoft.NET \ फ्रेमवर्क \ v4.0.30319 \ MSBuild.exe"

मैं बैच दो पंक्तियों से युक्त फ़ाइल बनाई:

@call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\setenv.cmd" 
@C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe %* 

और सर्वर को इस बैच फ़ाइल को बिल्ड कमांड के रूप में उपयोग करने के लिए कॉन्फ़िगर किया गया।

मेरा बिल्ड सर्वर जेनकिंस था, टीएफएस नहीं, लेकिन मुझे आशा है कि इससे आपकी समस्या भी हल हो जाएगी।

0

जॉनी कॉफ़मैन के जवाब के अलावा, मैं समस्या यह है कि मैं 11.0 नामित HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 में उपकुंजी था। इस कुंजी में HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A के संदर्भ थे जो मेरी मशीन पर मौजूद नहीं हैं। तो यदि जॉनी कौफमैन का जवाब मदद नहीं करता है, तो 11.0 कुंजी की जांच करें और इसे हटाने पर विचार करें।

संबंधित मुद्दे