Home Dashboard Directory Help
Search

GenerateResource fails for .Net 3.5 application when .Net 4.5 has been installed by Christian Bay


Status: 

Closed
 as Won't Fix Help for as Won't Fix


26
0
Sign in
to vote
Type: Bug
ID: 758772
Opened: 8/20/2012 9:15:43 AM
Access Restriction: Public
1
Workaround(s)
view
11
User(s) can reproduce this bug

Description

GenerateResource fails with the following error message, when the username of the user is 20 characters. 19 characters or less works fine.

------ Build started: Project: Test, Configuration: Debug x86 ------
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2299,5): error MSB4216: Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\MSBuildTaskHost.exe" exists and can be run.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2317,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Details
Sign in to post a comment.
Posted by sgtsurge on 1/28/2013 at 8:41 AM
I am also creating a build server and installed .NET 4.5 as needed for our build needs. Our username is only 6 chars long minus the domain name. The System Environment Variable fix doesn't work. I still get the same error.
Posted by BarrinTe on 1/4/2013 at 4:39 PM
I am facing the same issue. I have installed .Net 4.5 as part of the 2012 build agent install on the build machine.
The user name of the build account is only 8 characters.
Does it include the domain name?
Domain\UserName is Exactly 20 characters.

I created a System Environment Variable DisableOutOfProcTaskHost and set the value to true. Did not work.
I also added a project.csproj xaml file (didn't fix it):
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>

I'm obviously not doing something correctly. Thanks for any help.
Posted by Microsoft on 9/10/2012 at 5:40 PM
DisableOutOfProcTask host can be set as an environment variable globally or even a property in your project file.
Posted by kpdn on 9/4/2012 at 9:28 AM
Understandable. But to continue working at the moment I'll need to set it. Would you know where I should put that value at and set it to true?

Posted by Christian Bay on 9/4/2012 at 8:36 AM
Bacause there is a reason a new method was implemented so disabling it seems bad. But yes DisableOutOfProcTaskHost works for this issue but how knows what else it would break.
Posted by kpdn on 9/4/2012 at 8:31 AM
I'm a bit confused on the whole 20 bit character account usernames issue. I'm seeing this same error after installing .net 4.5 on my build machine as well. And trying to get a clear way to resolve the situation.

what is meant by 'change our build system to generate 19 characters account usernames instead'

and is this a valid fix, if so where does it go?
'DisableOutOfProcTaskHost=true'
?

Thanks!
Posted by Christian Bay on 9/4/2012 at 4:09 AM
Thanks for the feedback, that helped - we did change our build system to generate 19 characters account usernames instead.

We did not like the idea of something that not so well tested and enforced legacy behaviour, not knowing what else it might break now or down the road.
Posted by Microsoft on 8/27/2012 at 5:11 PM
The root cause of this problem is work we did in MSBuild 4.5 to fix the following bug:
If you have 4.0 on a 64-bit OS and are using either the 32 bit or 64 bit MSBuild or VS2010, and you build a Vb/C# project targeting 2.0/3.0/3.5, and it contains a .resx containing a reference to a type that was marked 32 bit only rather than MSIL, the build would fail.

The cause of the bug is that MSbuild 4.0 (appropriately) invokes the 3.5 resgen.exe in this case, since you are targeting 3.5, and resgen.exe was incorrectly marked as MSIL. (Resgen should have had separate 32 bit and 64 bit versions. This was partly fixed for the 4.0+ resgen.exe BTW) Because of this, on a 64 bit OS, resgen.exe will run as a 64 bit process. When processing a .resx with references to user types (typically happens when you are using a designer such as the winforms designer) resgen instantiates them; if the type requires 32 bit, it's now running in a 64 bit process so it fails. As you can imagine, this is a pretty rare situation. However we obviously want the build to succeed.

So, we employ a new feature in MSBuild 4.5: the ability for a specific task to request it is run on a worker process with a particular bitness and/or CLR version. Because you are targeting 3.5, to solve the problem above, it creates a 32 bit, 3.5 worker process and (effectively) loads resgen.exe inprocess. This all works fine unless you have a 20 character username. To communicate with the worker process, MSBuild uses System.IO.Pipes. This has an off-by-one in it that causes it to fail for a 20 character username. That was fixed in .NET 4.0, but not .NET 3.5. Because we are running on 3.5 in this situation, we hit the problem.

The only possible fix would be to service .NET 3.5. However, given it affects a relatively small number of customers, and there's a straightforward workaround, it would be unlikely to meet the bar for a patch.

The workaround should be reliable, although inevitably it wasn't as well tested. It is a supported codepath. It causes us to behave effectively the same as MSBuild 4.0 -- we don't use a worker process. So you will work with a 20 char username, but you don't have the fix to the bug above. I'm assuming the number of customers that have 20 char usernames AND satisfy all the conditions for the original bug to repro is vanishingly small.

Hope this helps
Dan / dev lead/ project+build
Posted by Christian Bay on 8/23/2012 at 4:10 AM
Could you elaborate on what caused this and why an undocumented switch is the proper solution? (What are the implications of setting it?)
Posted by Microsoft on 8/22/2012 at 4:09 PM
Thanks for your feedback. Please keep the host disabled.
Posted by Christian Bay on 8/22/2012 at 1:20 AM
Setting `DisableOutOfProcTaskHost=true` works.
Posted by Microsoft on 8/21/2012 at 2:57 PM
I haven't tried this yet, but what if you run VS (or MSBuild.exe) with an environment variable
DisableOutOfProcTaskHost=true
?
Posted by Microsoft on 8/21/2012 at 2:38 PM
Ack. Thanks we'll take a look.
Dan
Posted by Microsoft on 8/21/2012 at 4:09 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Microsoft Visual Studio Connect Support Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 8/20/2012 at 9:52 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by kosalaw on 1/15/2014 at 9:42 PM
We were able to fix this issue by reducing windows login name to 8 characters. For an example my previous login name was "kosala.wijegunaratna". After changing the login name to "kosala.w", resgen.exe started to work as expected.