GenerateResource task appears to be calling 3.5 version of resgen.exe instead of 4.0?
-
viernes, 17 de febrero de 2012 23:10
We have a utility that scans a source tree and generates MSBuild project files to build localization satellite assemblies. These project files contain a simple list of the input RESX files, a list of referenced assemblies (for a few special resource types), and make use of the GenerateResource and AL tasks to do its magic. This worked great when everything was .NET 3.5/VS2008.
A number of VS2010 projects were recently added to the source tree, and they build to target 4.0. For a few projects, GenerateResource fails hard giving the error "ResGen : error RG0000: Could not load referenced assembly "myproject.dll". Caught a BadImageFormatException saying "Could not load file or assembly 'myproject.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded." This happens even when the project file is built in a VS2010 command prompt, and even after modifying the generated project files to include ToolsVersion="4.0" and <TargetFrameworkVersion>v4.0</...>. Note that the referenced assembly "myproject.dll" is the main assembly for which the satellite was being built, and was indeed built to target 4.0.
We noticed something curious in the VS2010 projects that did build - they all logged the following:
Project "T:\myproject.es.proj" (default targets):
Target -GenerateResources:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\ResGen.exe /r:T:\bin\myproject.dll /compile data.es.resources
Target Build:
Creating directory "bin\".
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\AL.exe /culture:es /out:bin\es\myproject.resources.dll /template:T:\bin\myproject.dll /embed:obj\data.es.resources
Build succeeded.
0 Warning(s)
0 Error(s)Note that the AL task executed from the NETFX 4.0 Tools subfolder, whereas ResGen came from its parent. Both AL and Resgen have counterparts in both folders, and the ones in C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin report (in the tool's banner) .NET 3.5 / VS 9.0 whereas the ones in C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\ report .NET 4.0 / VS 10.
Any thoughts? It seems odd that two tasks in the same project file would select tools from different versions of the framework, especially since .NET 4.0 assemblies can't be consumed by 3.5 tools. It appears we can workaround this issue by updating the utility to generate scripts to call the correct ResGen using <Exec ...>, but somehow that doesn't look nearly as clean as simply calling <GenerateResource ...>
Thanks,
-T
PS: For what it's worth, the machine is 32-bit XP SP3 with both VS 2008 and 2010 installed.
- Editado Tamanator viernes, 17 de febrero de 2012 23:29 fixed typo and added emphasis on path
Todas las respuestas
-
martes, 21 de febrero de 2012 9:29
>>"Could not load file or assembly 'myproject.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
Please double-check whether your dll and its dependencies is .net 4.0. as you said the myproject.dll is target 4.0, I suggest you to create a new myproject.dll which target to 4.0.
Tamanator, The GenerateResource task is functionally similar to resgen.exe. why do you say the The GenerateResource task to be calling by resgen.exe.
http://msdn.microsoft.com/en-us/library/ms164295.aspx -
martes, 21 de febrero de 2012 16:08
Yes, thank you for pointing out the MSDN documentation. I understand most questions can be answered that way, but I do actually read those and they don't help in this situation.
Let me make this more clear:
- I have common.dll which is a .NET 4.0 assembly containing a type, let's say an enum for describing RTL behaviour.
- I have main.dll which is a .NET 4.0 assembly containing Windows Forms controls, one of which has a localizeable property of the type describing RTL behaviour.
- I am trying to build main.resources.dll which is the satellite assembly containing the localized resources for main.dll (in this case, for Spanish).
- One of the RESX files that are to go into main.resources.dll contains a resource definition using the RTL behaviour type. Therefore, compiling that RESX file will require being able to resolve common.dll
- The RESX files that are to go into main.resources.dll are compiled with <GenerateResource ...>
- For some reason, the build of main.resources.dll fails with the newer runtime error, despite the MSBuild project supposedly using tools version 4.0 and being run from a VS2010 command prompt. Note that I haven't even mentioned .NET 3.5 or .NET 4.5 yet in this post. Everything is .NET 4.0.
The MSBuild output log during includes a command line with arguments for resgen.exe which is output by the GenerateResource task. This command line includes the full path to the wrong version of resgen.exe. At best, the task doesn't actually call resgen.exe and this output is wonderfully misleading. At worst, it's calling the wrong version of resgen.exe. Regardless, it doesn't change the fact that I have a GenerateResource task that fails to resolve a .NET 4.0 assembly.
-T
-
viernes, 27 de abril de 2012 20:24
You probably found some workaround already, but maybe this can still be helpful:
Add the following two targets to your *proj file. This should force the GenerateResource task to use C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\ResGen.exe:
<Target Name="BeforeResGen">
<Message Text="Temporarily setting TargetFrameworkSDKToolsDirectory to $(SDK40ToolsPath)." />
<PropertyGroup>
<AmbientTargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)</AmbientTargetFrameworkSDKToolsDirectory>
<TargetFrameworkSDKToolsDirectory>$(SDK40ToolsPath)</TargetFrameworkSDKToolsDirectory>
</PropertyGroup>
</Target><Target Name="AfterResGen">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory>$(AmbientTargetFrameworkSDKToolsDirectory)</TargetFrameworkSDKToolsDirectory>
</PropertyGroup>
<Message Text="TargetFrameworkSDKToolsDirectory restored to its previous value, $(TargetFrameworkSDKToolsDirectory)." />
</Target>
- Editado Ron Inbar, Haifa viernes, 27 de abril de 2012 21:53 typo

