هل يمكن لـ Vs.net 2010/msBuild إنتاج XmlSerializers لـ .NET 3.5 SP1؟

Question

لقد قمت للتو بترقية حل VS 2008 الذي يحتوي على WinForms ، ومكتبات الاستخدام العام ، وتطبيق ويب إلى VS 2010 ، ولكن لا تزال جميع المشاريع تستهدف .NET 3.5 SP 1. أنا أستخدم هذه التقنية لإنشاء XMLSerializers لمكتبات الاستخدام العام. تطبيق WinForms يعمل بشكل جيد. عندما يحاول تطبيق الويب الخاص بي التشغيل باستخدام هذه المكتبات التي تشير إلى نفس XMLSerializers ، فإنه يرمي ما يلي:

خطأ الخادم في تطبيق '/websubscribers'. لا يمكن تحميل الملف أو التجميع 'CEOIMAGE.BASECAMP.XMLSERIALIZERS أو واحدة من تبعياته. تم تصميم هذا التجميع بواسطة وقت تشغيل أحدث من وقت التشغيل الذي تم تحميله حاليًا ولا يمكن تحميله. الوصف: حدث استثناء غير معقد أثناء تنفيذ طلب الويب الحالي. يرجى مراجعة تتبع المكدس لمزيد من المعلومات حول الخطأ وأين نشأت في الكود.

تفاصيل الاستثناء: System.BadImageFormatexception: لا يمكن تحميل الملف أو التجميع "الرئيس التنفيذي. تم تصميم هذا التجميع بواسطة وقت تشغيل أحدث من وقت التشغيل الذي تم تحميله حاليًا ولا يمكن تحميله.

لقد نظرت إلى مراجع XMLSerializer باستخدام .NET Reflector ويرونها تشير إلى كل من إصدارات 2.0 و 4.0 من mscorlib وكذلك إصدارات 3.5 و 4.0 من System.Data.Linq. الغريب ، إنه يستخدم فقط الإصدار 4.0 من System.Xml. ربما هذه هي مشكلتي هناك.

كيف يمكنني تشغيل تطبيق الويب باستخدام أجهزة XMLSerializers هذه؟ عندما أقوم ببساطة بحذف XMLSerializers ، يعمل تطبيق الويب بشكل جيد. هذا خيار ، ولكن كيف يمكنني إجبار MSBuild على إنشاء مسلسلات لإصدار معين من CLR؟

فيما يلي مهمة MSBuild التي أضفها إلى ملفات المشروع التي تفرض إنشاء XMLSerializers:

<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
 <Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
 <SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
  <Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
 </SGen>
</Target>

Answer 1

لقد وجدت أنه يمكنني تحديد مسار أدوات مهمة SGEN بشكل صريح لاستخدام الإصدار 3.5 ، مثل ذلك:

<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin">

Answer 2

سوف MSBUILD 4 (يجب ...) استخدام 3.5 أدوات لبناء 3.5 مشاريع. ومع ذلك ، يبدو أنه لا يمكن أن ينجح في مكان وجود أدوات 3.5 وتستخدم الأدوات 4.0. والنتيجة هي أنه يقوم ببناء مشروع 3.5 بشكل صحيح (مع مجموعات CLR 2.0.50727) ، ولكن أداة SGEN.EXE 4.0 تقوم بإنشاء الرئيس التنفيذي.

يستخدم MSBuild السجل للحصول على المسار إلى أدوات V3.5. ستعود مهام MSBuild التي تتطلب أدوات V3.5 SDK إلى مسار V4.0 إذا كان لا يمكن تحديد المسار إلى أدوات 3.5 - انظر إلى المنطق المستخدم لتعيين خاصية TargetFrameworksDkToolsDirectory في C: Windows Microsoft. Net Framework v4.0.30319 microsoft.netframework.props إذا كنت مهتمًا حقًا.

يمكنك تشخيص ومشاكل التسجيل الممكنة على النحو التالي:

تثبيت مراقبة العملية وإعداد مرشح لمراقبة الوصول إلى السجل بواسطة MSBuild (فئة الحدث: السجل ، اسم العملية: msbuild.exe ، جميع أنواع النتائج)

قم بتشغيل بنيتك

مراقبة عملية البحث لمطابقة وصول RegqueryValue "MSBuild Toolsversions 4.0 SDK35ToolSpath". لاحظ أن هذا يمكن أن يكون إما تحت "hkey_local_machine software microsoft" أو "hkey_local_machine software wow6432node microsoft"

إذا كان لديك نظرة على هذا المفتاح في السجل ، فسترى أنه يسمم قيمة أخرى للتسجيل ، على سبيل المثال "$ (registry: hkey_local_machine softwar التثبيت)) "بعد ذلك بوقت قصير ، سترى على الأرجح نتيجة" لا يتم العثور عليها "حيث يحاول MSBuild تحميل القيمة من المفتاح المحدد.

يجب أن يكون واضحًا المفاتيح التي تحتاج إلى إضافتها / تعديلها من هنا.

هناك بعض الأسباب المحتملة التي تخطئ قيم السجل. في حالتي ، تعني مشكلة تثبيت Microsoft SDK V7.1 أن مفاتيح التسجيل تم تسميتها بشكل غير صحيح ، والتي تم تحديدها على أنها خطأ هنا:

http://connect.microsoft.com/visualstudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedd- مصادر

Answer 3

هل تعتمد على أي شيء 4.0 محدد؟

إذا كنت تستدعي MSBuild 4.0 ، فستحصل على 4.0 أدوات. إذا كنت تستدعي MSBUILD 3.5 ، فستحصل على 3.5 أداة (وهو ما تريده لأنك تستضيف بوضوح في 2.0 CLR).

الخيار الآخر هو وضع 4.0 CLR على خادم الويب الخاص بك. إذا لم يكن ذلك مفتوحًا ، فلا ينبغي أن يكون لديك أي أشياء مستهدفة 4.0 في دفقك.