Error when compiling .resx file. Seems related to Beta2 bug 5252020

File Name	Submitted By	Submitted On	File Size
ResourceFrm.resx (restricted)	Theo_plugwise	2/10/2010	-
ResourceFrm.resx (restricted)	Theo_plugwise	2/10/2010	-
ResourceFrm.resx (restricted)	Theo_plugwise	2/10/2010	-
TestForm.zip (restricted)	Theo_plugwise	2/11/2010	-

Posted by Talos on 5/8/2013 at 5:43 AM

We resolved this issue by installing Visual Studio 2012 side by side with Visual Studio 2010. Without changing the project's target framework 3.5, the RESX file compiled successfully in Visual Studio 2010.

We had noticed that this issue did not repro on developer machines that had both Visual Studio 2010 and 2012 installed on Windows 7 64-bit systems. Installing Visual Studio 2012 also installs .NET Framework 4.5, which according to an earlier post by Chuck England, fixes this issue.

Posted by Iain Galloway on 4/30/2013 at 9:41 AM

I can confirm that this is *not* fixed.

Posted by Rayzer on 4/2/2013 at 3:21 AM

Just ran into all of this crap today.. Not good enough when you read the posts here.. Workarounds are fine but i'm afraid to touch anything now...

Posted by Matthias Loerke on 10/10/2012 at 12:57 AM

Bumped into the issue building a .NET 3.5 project. Workaround did it but agree that this is NOT a real solution.

Posted by cheapshot2005 on 9/28/2012 at 10:35 AM

Concur that this is still not fixed. The workaround of changing (00 back to 0y) is working for now; but something official from MSFT would be nice.

Posted by Paul Müller23 on 6/18/2012 at 9:34 AM

This problem is clearly NOT resolved. Any official workaround provided by Microsoft does not work! It has to be possible to compile a project in VS 10 for .NET 3.5 on a 64bit machine. This situation is ridiculous.

Posted by DanyR on 6/4/2012 at 10:29 PM

BTW, I believe that this whole business will eventually be a goner by watching the progress of MS with VS2012/Win8. IMHO desktops and thus the industries are doomed, because money-making is only working with consumers and not those boring industrial applications and their needs. :-/

Posted by DanyR on 6/4/2012 at 10:22 PM

@Oleksandr Pshenychniy

We encountered that while changing the target framework from 2.0 to 4.0 works just fine, the other way round leaves fragments of 4.0. Maybe thats also your case. Please take a look into the *.Designer.cs if there is a textual reference wit 4.0. On the other hand, this should lead to an error while compiling not on runtime...

Posted by Oleksandr Pshenychniy on 5/28/2012 at 8:43 AM

I have related issue too. Actually, Gneuh already mentioned about it on 16/02/2011. Unfortunately I haven't found any answer to it and different workarounds, proposed by Microsoft and other people doesn't help (I searched many of the forums and articles, including corflags 32bit for resgen, fixing .proj file in notepad etc. I will not list all attempts as they doesn't give anything).

So, the problem is: on run-time (NOT compile-time) in the form designer code 'resources.GetObject("myImageName")' I get exception FileNotFoundException:
Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
at System.RuntimeTypeHandle._GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName)
at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
at System.RuntimeType.PrivateGetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
at System.Type.GetType(String typeName, Boolean throwOnError)
at System.Resources.ResourceReader.FindType(Int32 typeIndex)
at System.Resources.ResourceReader.DeserializeObject(Int32 typeIndex)
at System.Resources.ResourceReader.LoadObjectV2(Int32 pos, ResourceTypeCode& typeCode)
at System.Resources.ResourceReader.LoadObject(Int32 pos, ResourceTypeCode& typeCode)
at System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase, Boolean isString)
at System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase)
at System.Resources.ResourceManager.GetObject(String name, CultureInfo culture, Boolean wrapUnmanagedMemStream)
at System.Resources.ResourceManager.GetObject(String name)
[MYAPP stack trace part. Hope you don't need it]
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

I have Windows 7 x64, VS 2010, .NET 4.0 installed. VS project has TargetFramework=2.0.
Windows form contains resx resource file with 2 icons. There is no references to 4.0 assemplies in resx file - all references use 2.0 versions (but I read somewhere that it doesn't matter and is ignored, using 4.0 by default).
The first image (which loading causes beforementioned exception) contains "j0y" on the "key" position of the first line, as recommended.
Second image starts with line "AAABABcAMDACAAEAAQAwAwAAdgEAACAgAgABAAEAMAEAAKYEAAAQEAIAAQABALAAAADWBQAAAAAQAAEA" not containing neither "j00" nor "j0y" (It's name is "$this.Icon" and looks like being some standard generated icon for the form).

The most strange thing with this problem is that it appeared suddenly - nothing actually was changed and the project stopped working. I spent the whole day investigating and trying different approaches. Unfortunately nothing helped, as I said.

Please, help.

Posted by Nate Shoffner on 5/15/2012 at 5:11 AM

This issue is still alive and kicking. Experienced it using WinForms ImageList with .NET 2.0 (VS2010).

Posted by Lockwood on 5/1/2012 at 3:17 AM

I'm still stuck with this, I'm already on "No code generation" and there is not j00 to change to j0y for me.

Posted by Dax Fohl on 4/4/2012 at 9:38 AM

I had this problem and found it oddly had to do with .Net 4.5 beta. Uninstalling that, and reinstalling .Net 4.0 caused the problem to go away. Not sure if there's a way to have .Net 4.5 beta installed _and_ use resources from a .Net 2.0 project simultaneously.

Posted by makasov on 1/31/2012 at 12:32 AM

You have to open the resx File in the Designer and set the accessmodifier from public to no code generation.

Thats it!

Posted by MedBiller on 1/5/2012 at 5:43 PM

As of 1/5/2012 9:37PM, absolutely NOT FIXED! Will they fix it before the end of the world?

Posted by Rance Mohanitz on 12/19/2011 at 2:24 PM

My whole office upgraded to 2010 Ultimate last Friday. This morning we ran into this problem, and one of our astute devs found the AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w to AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w workaround floating around on Google or we would have been completely hosed! As it stands now, every time one of us updates something in Designer, we have to manually make the above change in the resource file. This sucks, Microsoft! A LOT of money has been spent, where is the fix that is apparently 22 months in the waiting? Gahead Dooit!

Posted by elvedrano on 11/23/2011 at 5:26 AM

This bug is making my life miserable... Release a hotfix already.. dammit :(

Posted by remohy1 on 9/29/2011 at 3:03 PM

I have seen some funny guys in here but they are not funnier than Microsoft. "Microsoft", we will fix it next releases in 20** and we do not care about the money that you paied. Anyway, just a help, This error is not at the image resources only. This error happened with me @ MemberInfo Objects like the MethodInfo and the PropertyInfo.

Good luck in 20** or may be 21**!

Posted by CleverCoder on 9/23/2011 at 6:45 AM

If it's fixed for VS 2010 (which we use every day), where's the fix going to be?

Posted by Andycted on 9/22/2011 at 9:56 AM

Wow. Closed ? Seriously ? That's pretty much unusable and the workarounds are almost no-go !

Posted by -Pete Thompson on 8/16/2011 at 12:46 PM

Just ran into this bug after upgrading our application from VS2008 to VS2010. Yay.

After reading a bit of history behind the bug, the workarounds seem pretty insane, and it also seems pretty insane that this was actually closed as fixed for 2011...

This really needs a hotfix, y'know. Right now VS2010 is pretty unusable unless we go through all the forms and strip out the ImageLists, and pray that there isn't another resource type that would trigger the same problem...

Posted by Martin Packwood on 8/16/2011 at 1:54 AM

I've been hit with this and wasted a several days of effort. More than it would take to fix the bug, probably. Having read the history I can't believe it's still not fixed. We now have a series of patch utilities being offered by many of the developers that have had to work around it.

For the record this is a plain simple bug with V4.0.0.0 of Windows.System.Forms.DLL embedded in the image list stream when it should be V2.0.0.0 when you target .net framework 2.0.

A fix would be nice.

Posted by Sebas--- on 8/10/2011 at 1:37 AM

The work arounds are just bad, even now SP1 is released this bug isnt fixed.

Why did they close this as 'Solved' ???

Posted by DigitalJonah on 5/11/2011 at 6:24 AM

This is nuts... almost 2 months later.. with the SP installed and it still doesn't work?

MSFT... What happened to.. DEVELOPERS DEVELOPERS DEVELOPERS

I love VS2010, the improvements to web dev are great, starting to use WPF a bit more, but not being able to use WinForms in .Net 2.0 for older (yet very active) projects is like knee capping me!

Posted by timfriesen on 5/11/2011 at 6:19 AM

The workarounds for this issue are rediculous. The only proper workaround is fixing this issue! Period!

Posted by Microsoft on 3/21/2011 at 9:58 AM

Sorry we were not able to fix this sooner. The issue has been fixed in our codebase. It will be made available in a future release (servicing or product release).

I can't guarantee when, as we have have a bar for fixes going into servicing releases to make sure we do not destabalize the system for those who do not have the issue. Each issues is fixed for a particular release in a concious effort to provide the highest realiability for all users.

If you need something faster, you can try and open a service ticket with Product Support. They have the best ways to potentially get you a fix, or a work-around for the problem.

Posted by dvlg on 3/13/2011 at 5:38 PM

Microsoft, you want to fix that in VS 2012? That's a joke, isn't it? We've paid lot of money for VS 2010 and cannot use it for our main application. We are forced to use VS 2005 for development, because we've skipped 2008. Is it so difficult to release an update for your current version? Why didn't it make it in SP1, this was reported more than a year ago!

Posted by DanyR on 3/7/2011 at 11:11 PM

Dear Microsoft,

the incorrect serialization is IMHO no "additional" issue but one of the most common reasons for the problems (I estimate it to solve >75%). How can it be, that a reference to .NET 4.0 enters the code of a pure .NET 2.0 or 3.5 solution?

Is it really so hard to fix it in VS2010 that you are "forced" to put it in the next release (VS2012 or what)? You can't be serious!

BTW, did you know that ImageList serialization damages the (PNG) alpha channel with each new save process (since the beginning of .NET) which is also very annoying?

I'm very crestfallen because of such an attitude. I should have cancelled my MSDN subscription (the second installment was callable just now) but "hope dies last".

Posted by Microsoft on 3/1/2011 at 1:45 PM

Thanks for all the feedback on this set of issues.

At this point, we have addressed the issues of running RESGEN in the wrong bitness on x64, which causes this error. This did not make it for SP1, but should make it in the next release of Visual Studio.

Here are some links to some associated documentaiton that may help with these types of issues.

http://blogs.msdn.com/b/visualstudio/archive/2010/06/19/resgen-exe-error-an-attempt-was-made-to-load-a-program-with-an-incorrect-format.aspx

http://blogs.msdn.com/b/visualstudio/archive/2010/02/16/if-your-build-fails-with-msb6002-the-command-line-for-the-resgen-task-is-too-long.aspx

http://blogs.msdn.com/b/visualstudio/archive/2010/05/07/building-on-cross-targeting-scenarios-and-64-bit-msbuild.aspx

As a result or the above, we are marking this issue as fixed.

Note that there is an additional issue regarding incorrect serialization from the designer. This was found to be related to Windows graphics library bug, which has been filed with Windows to fix.

Posted by Henryay on 2/24/2011 at 9:46 PM

I also tried replacing "j00" with "j0y" and it works. Thanks! This really needs to be fixed.

Posted by Pellet21 on 2/24/2011 at 2:18 PM

We ran into this problem recently after upgrading to VS2010 and then having to downgrade to .NET 3.5 due to compatibiility problems with another application that we integrate with. Affter many hours of researching this I was able to get the below workaround to temporarily bypass this BUG. WHEN IS MICROSOFT GOING TO fix this? Why is this BUG still Active from Feb 2010? This is a royal pain for us...

Workaround
1.    Open Form in Designer and make needed GUI changes. Close designer and save
2.    Compile project and receive RESX compile error (only forms with Imagelist should have this problem)
3.    Double-click resx compile error to open resx file.
4.    Scroll to top of imagestream.
5.    Edit the top line of the Image stream:
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w
TO
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w
6.    Close and save resx file and recompile.
**NOTE: the only difference are the characters at end "j00LjAuMC4w' to "j0yLjAuMC4w"

This needs to be done EVERY TIME you open the form in Designer mode.

Posted by Gneuh on 2/16/2011 at 9:24 AM

I'm also having this problem I used the 32BIT flag workaround, it works a time, but it's very unstable, I've got 2 issues with it :
- ResGen.exe very slow (up to 30 minutes to compile my project, ResGen.exe using 50% of a cpu core during this time)
- Sometimes bug in application due to FileNotFound Exception caused by a resource loading trying to link with Microsoft.Windows.Form 4.0 (my program is in .NET 3.5)

I installed SP1 beta with hope to solve this issue, but its still the same.

Please help us !!!

Posted by J. Zumwalt on 2/15/2011 at 7:20 PM

+1 for a fix. Hopefully in SP1?

This is impacting our ability to develop and we might have to downgrade to 32bit.

Also saw the same issue when trying to update a WCF proxy reference. Seems WcfSvcHost.exe also runs as 64bit only.

Posted by Alex Sorcinelli on 1/5/2011 at 2:28 AM

This bug is very important for us.
I would like to know if it's fixed in SP1 beta or if it will be inclued in the SP1 RTM.
Thanks

Posted by dvlg on 12/10/2010 at 6:44 AM

I think this is fixed in SP1 Beta, can anyone confirm this?

Posted by Ed Hartley1 on 9/2/2010 at 4:51 PM

The j00L -> j0yL workaround does work for me, however its a bit ridiculous to have to do that everytime you edit a form with an image list on it. Clearly a relatively minor bug in the image list control causing us a stack of pain.

Posted by rellis3264 on 8/23/2010 at 8:46 AM

Voted this one up. I have a 32-bit project (which must stay 32-bit because of a 3rd party DLL) where ResGen is apparently rejecting a form because another type, elsewhere in the same project, references a 32-bit interop DLL. On paper there's no connection that should cause ResGen a problem.

Posted by Theo_plugwise on 7/26/2010 at 2:54 AM

This is a nice one. In this report they refere to #554759. In that report they refere to this report... We're lost in an endless loop...

>>We made the wrong call on this one by closing it. I've reactivated 532584 which has the same underlying cause (so I'll leave this one closed -- but I'll not ignore the vote count on it). We're looking into the fix.

Posted by Microsoft on 7/25/2010 at 2:58 PM

Based on the number of votes, this should be fixed. Wrong call on our part. Reactivating.

Note there are some dupe reports of this with the same underlying cause, such as 554759. I'm going to leave those closed, since they need the same fix.

Posted by Matteo Prosperi on 7/7/2010 at 9:23 AM

I have experienced a similar problem with a project converted from Visual Studio 2008 to Visual Studio 2010 on Windows 7 x64.
The converted project works fine.
Adding an image to an ImageList the first row of data in the resx file changes from
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w
to
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w
for all the ImageLists in the resx file.
After this change the resx will not complile anymore.
I have to change back the "00LjAuMC4w" to "0yLjAuMC4w" so that the resx file compiles again.
An alternate solution is to set the 32bit flag to ResGen.exe with Corflags to make the resx compile but then I have to manually add <ResGenToolArchitecture>Managed32Bit</ResGenToolArchitecture> to all the project files compiling resources!
I have read everywhere about this and similar bugs that it is related to mismatched target platforms but if it is so why I can solve everything just editing one byte in the ImageStream?
Please solve this problem as soon as possible!
Thank you

Posted by Microsoft on 6/22/2010 at 11:33 AM

We are currently trying to reduce our bug debt. Based on the comment that you have an acceptable work-around, I am resolving this bug.

Thanks,

Chuck England
Visual Studio
Program Manager - MSBuild

Posted by Microsoft on 6/21/2010 at 11:58 AM

Thanks for taking the time to report this issue to us.

We have recently released a post on the Visual Studio Blog that explains this issue.

http://blogs.msdn.com/b/visualstudio/archive/2010/06/19/resgen-exe-error-an-attempt-was-made-to-load-a-program-with-an-incorrect-format.aspx

Please take a look and see if this resolves your issue.

Thanks,

Chuck England
Visual Studio
Program Manager - MSBuild

Posted by J. Clay on 6/9/2010 at 3:48 PM

I am having the issue as well and Any CPU doesn't help, but Luis Mack's workaround does work for me. Not very fun, but I am in maintenance mode so it is workable.

Posted by red_seven on 6/8/2010 at 2:23 PM

I too am having the same issue. Really regret upgrading to VS 2010 as trying to deal with this issue is causing major problems and productivity using 2010 with projects upgraded from 2008 is so slow it's just not worth dealing with

Posted by Tim Hall on 5/27/2010 at 10:54 PM

The proposed solution to this is not acceptable: i regret migrating to VS2010 now, it clearly wasn't ready.

This is real issue with VS2010 on 64bit machines, while setting to any cpu fixes the problem, it breaks edit and continue because ms still haven't got that working for 64bit apps, thankfully my main machine is 32bit because but the other machines are not as lucky.

The problem is reproduced on Win7 64bit, VS2010 Ultimate running as administrator. The corflags trick just makes the problem worse. I hope that you will take this more seriously and that a real fix is released asap.

Posted by mkchandler on 5/12/2010 at 11:39 AM

I am getting this same exact error when compiling on Windows 7 Enterprise x64, using Visual Studio 2010 Ultimate.

I would like to let everyone know that Luis Mack's workaround that was posted today (May 12th, 2010) worked for me. Hopefully this bug will get fixed soon!!

Posted by deepfm on 5/8/2010 at 2:19 AM

After set 32BIT on Resgen.exe with corflags I'm getting this error in 2 projects:

Error 4 Failed to execute command: ""D:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ResGen.exe" /useSourcePath "/r:.... [LOST OF DLLs] ...

The handle is invalid. [PROJECT PATH]\TRACKER

File : TRACKER

Posted by deepfm on 5/8/2010 at 1:28 AM

We've the very same problem. Could you give me more information about marking resgen.exe 32bit only?

I've run this

corflags.exe /32BIT+ /Force Resgen.exe

But now everything fails:

Error 5 Failed to execute command: ""D:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ResGen.exe" /useSourcePath .........

Posted by Theo_plugwise on 4/12/2010 at 6:11 AM

Hi Dan,
Sorry for this late reply.

Building the assembly as 'AnyCPU' does indeed do the trick. For me, that is an acceptable workaround.

Thanks!

Posted by Microsoft on 4/5/2010 at 4:32 PM

I made a comment earlier, but it vanished - sorry about that. Here's what i believe the issue is:

The resgen for the 3.5 tools in v7.0A\bin\resgen.exe is marked as MSIL. On a 64 bit machine this is launched as a 64 bit process. Plugwise.Util.dll is built as a 32 bit only assembly. When this assembly is attempted to be loaded into the resgen process we get the load failure:

There are two work arounds

1) Build Plugwise.Util.dll as a AnyCPU assembly
2) Use the corflags tool on the resgen.exe in the v7.0A\Bin directory and mark the exe 32 bit only. However if you do this you would want to copy the resgen.exe tool before running corflags into the X64 directory so that we have a version which can load 64 bit assemblies in it.

Going forward, the 4.0 resgen (used when targeting 4.0) is marked explicitly as 32 bit. There's also one marked 64 bit. So we should be good there.

Does this work?
Dan

Posted by Microsoft on 2/15/2010 at 5:20 AM

Thanks for your feedback again!
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.These specialized experts will follow-up with your issue.

Posted by Theo_plugwise on 2/11/2010 at 2:34 AM

Good news! I'm able to reproduce the error with a dummy project, using classes from the original project. I'll attach the zipped solution.

Posted by Microsoft on 2/11/2010 at 12:35 AM

Thank you for taking the time to report this issue.But we are unable to reproduce this bug.Could you please attach a zipped project to help us reproduce it?

Posted by Microsoft on 2/10/2010 at 7:03 PM

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)

Posted by timfriesen on 6/27/2011 at 8:53 AM

A tangable and workable workaround for those interested is to create a new macro within VS2010 (see below):

    Sub VS2010ResXReplacement()
        If (Not DTE.ActiveDocument Is Nothing) Then
            If (System.IO.File.Exists(System.IO.Path.ChangeExtension(DTE.ActiveDocument.FullName, ".resx")) AndAlso DTE.ActiveDocument.ProjectItem.Saved) Then
                Dim sResX As String
                sResX = System.IO.Path.ChangeExtension(DTE.ActiveDocument.FullName, ".resx")

                Dim sResXString As String
                sResXString = System.IO.File.ReadAllText(sResX)

                If sResXString.Contains("eXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00") OrElse sResX.Contains("NC4w") Then
                    System.IO.File.WriteAllText(sResX, sResXString.Replace("eXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00", "eXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0y").Replace("NC4w", "Mi4w"))
                End If
            End If
        End If
    End Sub

This macro simply takes the name of the current active document and tries to find a resx file. If found, it does a string replacement, in essence changing the Version from 4 to 2 in the 64 bit encoded strings found within imagelists.

Some of the developers in my office then assign a keyboard shortcut to the macro and some add a toolbar button. Then when we hit this compile error, they press the key combo or toolbar button and try again.

Note: the second part that is replacing ("NC4w", "Mi4w") is only needed if you are using Infragistics dock manager.

Posted by DanyR on 11/5/2010 at 12:21 AM

I decoded an ImageStream with "j00L" and "j0yL" and found out, that in VS2010 MS is serializing ImageLists with a reference to System.Windows.Forms, Version=4.0, even when the project is set to 2.0. The tip changes exactly this ("0" to "y" changes "4" to "2").

I attached a small tool named Set2010ImageListsToNET2 to the "problem duplicate" 554759 (see link above, because I can't attach it here). It takes a single resx or a path to be patched. You may freely use it and have a look at the source with Reflector.

Dear Microsoftians, please fix it ASAP.

Daniel

Posted by Poohshoes on 7/12/2010 at 6:56 AM

http://blogs.msdn.com/b/visualstudio/archive/2010/06/19/resgen-exe-error-an-attempt-was-made-to-load-a-program-with-an-incorrect-format.aspx

Solution 2.

Posted by Chuck England - MSFT on 6/21/2010 at 11:59 AM

Please see our post on the Visual Studio Blog:

http://blogs.msdn.com/b/visualstudio/archive/2010/06/19/resgen-exe-error-an-attempt-was-made-to-load-a-program-with-an-incorrect-format.aspx

Chuck England
Visual Studio
Program Manager - MSBuild

Posted by Luis Mack on 5/12/2010 at 8:50 AM

I've found the same problem, only for a specific project when compiling on a 64-bit machine. A fix that SEEMS to work is to manually alter one character in the image stream EVERY TIME the usercontrol or form is edited in the designer

<data name="icons_20.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
     AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Change to
     AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w
That is 00LjAuMC4w back to 0yLjAuMC4w at the end of the line (00 back to 0y)

Onerous, but at least a path forward.

Error when compiling .resx file. Seems related to Beta2 bug 5252020 by Theo_plugwise