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

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 758772 Comments
Status Closed Workarounds
Type Bug Repros 16
Opened 8/20/2012 9:15:43 AM
Access Restriction Public


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 ==========
Sign in to post a comment.
Posted by B6692 on 4/3/2016 at 3:39 AM
I am having several issues since I upgraded my .Net App built with Visual studio 2008. The issue this thread addresses is one of them. I upgraded my app because I would like to take advantage of the functionalities in .Net 4.0 and later. I have been getting a lot of errors which for the most part are thrown from visual studio designer generated code such as DataSets, Linq to SQL, Cryptography. The errors I get are usually different but I have noticed that they are mostly related to the mismatch between 32 bit and 64 bit .Net framework types (I am now using Win 7, Visual Studio 2013, 64 bit). I usually get "System.AccessViolationException occurred in mscorlib.dll", managed Debugging Assistant "FatalExceptionEngineError" error messages. often times I get the error telling me that the System.Windows.forms.pdb or mscorlib.pdb files were not found or failed to load or something similar I have read all the documentation on migrating my app and have tried all the reasonably related suggestions, but nothing seems to work and this issue is now getting into my bones. I followed one suggestion in one of these threads where it was suggested to delete the .suo file and restart VS, when I did, I now get the issue this thread is treating.

What would you suggest? Is there anything I am missing? I do not wish to migrate my app to run on 64 bit systems, It works fine on compatibility mode and would prefer to keep it that, but I would definitely like to take advantage of the newer .Net Framework functionalities without breaking my app.

By the way my username on the machine I am using including the domain name is not more than 15 characters. Also, I believe this issue is frequent enough for those who do migrations of apps.
Posted by Joel McBeth on 4/1/2015 at 10:19 AM
"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."

20 char user names are probably more common than you expect now that you can use your Microsoft Account email to log into Windows.
Posted by aedna on 9/30/2014 at 6:49 AM
I had only "C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A" folder, I copied it and renamed it to "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A" and that fixed my problem.

It's a twist on a solution described in
Posted by Jonathan Cage on 9/10/2014 at 3:00 AM
I have a short username but I'm still hit by this issue. Re-building from a clean build appears to solve it at least temporarily for me but that doesn't help on our build server.
Posted by Oleksiy Gapotchenko on 6/25/2014 at 2:31 AM
Unfortunately there is still no reliable workaround. My user name is only 2 chars long still I hit the problem every day. Deleting bin and obj folders helps but the problem comes back after a while. Please pay the appropriate attention to this issue. It hits badly on an *everyday* basis. The claim that the issue is rare is just wrong.
Posted by Vidyasagar Machupalli on 6/16/2014 at 12:38 AM
Tried all the suggestions in the thread and only the Windows login change(workaround) worked for me.
Posted by richwerner 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):

I'm obviously not doing something correctly. Thanks for any help.
Posted by Dan [MSFT] 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?

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 Dan [MSFT] 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 Richa [MSFT] 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 Dan [MSFT] 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
Posted by Dan [MSFT] on 8/21/2012 at 2:38 PM
Ack. Thanks we'll take a look.
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(