Home Dashboard Directory Help

Error in control resx file, when adding imagelist by workandparty


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 554759
Opened: 4/27/2010 6:30:58 PM
Access Restriction: Public
Primary Feedback Item: 532584
User(s) can reproduce this bug


Program can't build due to error in resx file.
We need .NET Framework 3.5 (with 4.0 works fine). Also we need build x86 target (with x64 works fine). Active solution platform - x86 also.
Create winforms project and class library project. Add some class (default Class1, for example and inherit this class from any standart control. Example TabControl). Build solution. Place new control (Class1) on Form1. Also place ImageList here. Fill imageList with png files. Try to run program.
Sign in to post a comment.
Posted by Tapsa- on 6/27/2013 at 12:47 AM
I can also confirm that this bug IS NOT FIXED. This is most time taking bug in visualstudio and it is still there. When you develop fulltime c# software it usual meant that you struggle several hours in every month with this problem.
Posted by Nefariousity on 8/3/2012 at 1:48 PM
Correction: as of 8/3/12
Posted by Nefariousity on 8/3/2012 at 1:47 PM
This is still not fixed as of 7/3/12. I'm building to x86 on a Windows 7 x64 machine and my imagelist is still causing this bug.
Posted by was-nb on 6/20/2012 at 1:49 AM
This is NOT fixed.
Still occurs in VS2010 using .NET 3.5.
Posted by DanyR on 6/4/2012 at 10:36 PM
I guess with Metro this would be no issue anymore and therefore considered as closed (I haven't had the time yet to test it with VS2012RC and WinForms .NET2.0). I'm really scared by the progress of the dwindling desktop support (I mean the real thing, not that "click instead of wipe" Metro thingy).
Posted by CodeScrubber00 on 4/23/2012 at 1:10 PM
Pellet21, Thank You.

Microsoft: Are you kidding? Closed? Fixed?
Posted by MedBiller on 1/5/2012 at 5:37 PM
As of 1/5/2012 9:37PM, absolutely NOT FIXED! Will they fix it before the end of the world?
Posted by JamesBombard on 11/9/2011 at 1:52 PM
It is not fixed. Now one of my screens has toolbars docked top and left and are not properly placed causing unwanted overlapping. have to "fix" the j00 to j0y at every compile.
Posted by jjhii on 11/2/2011 at 8:25 AM
as of the latest version of VS 2010 it is still not fixed! The j00l work around helps but is a time consuming pain.
Posted by kbocy1 on 10/31/2011 at 10:45 AM
Pellet21 - So many thanks for finding and posting the workaround for this problem. It works wonders. Thanks
Posted by Andycted on 9/22/2011 at 9:50 AM
It's typical. Since 4.0 > 3.5 , they won't fix it and just wait for 3.5 to go away...
Posted by Richard-B-AJB on 8/17/2011 at 5:02 AM
This infuriating issue is far from fixed. I've just been through a very painful process whereby I was updating images in ImageLists across several WinForms. For each form that was changed (and on every change that I made, i.e. several per form), I've had to do this workaround of editing the form's .resx file manually.
Posted by PaulBeaul on 8/16/2011 at 12:51 PM
Sebas is correct the bug is NOT fixed!!
Posted by Sebas--- on 8/10/2011 at 1:39 AM
And as a side note, a work-a-round is not a fix.
Posted by Sebas--- on 8/10/2011 at 1:38 AM
This bug is NOT fixed.
Posted by Etienne Poirier on 7/20/2011 at 2:26 PM
I'm using VS2010 version 10.0.40219.1 SPIRel and I also have that bug when compiling my project in Target framework 3.5.
When I compile it in 4.0 it is working.

In which version/hotfix is this bug fixed (if it is indeed fixed) ?
We want to compile our application on framework 3.5 and I don't like having to use a weird workaround...
Posted by Harald Binkle on 6/16/2011 at 6:02 AM
It's tagged as fixed, but with which version of VS2010 is it fixed?
I'm sing VS2010 version 10.0.30319.1 and it still occurs.
Posted by FredyLD on 6/3/2011 at 10:07 PM
Excuse about my English... In my project I had imagelists with ColorDepth in Depth8Bit, 24Bit and 32Bit. I changed all to 32Bit and re-added pictures. After that, everything worked well. Just try it.
Posted by hyiothesia on 6/1/2011 at 10:09 AM
In my case all I needed to do was change 1 of our 291 projects in the solution to "Any CPU" instead of x86.
Posted by Lionel Johnson on 4/2/2011 at 1:42 PM
Pellet21 - Many, many thanks for finding and posting the workaround for this problem. You have saved me an awful lot of time (already wasted enough time on it).

Microsoft: Get it fixed will you.
Posted by Blumidoo on 3/28/2011 at 2:56 PM
I have wasted an entire day hunting down reasons of this error and blaming PostSharp. When I found out it has been ImageList, I could not believe it. Now I am even more astonished seeing that almost one year after this bug has been posted, is is still not fixed.
Posted by thomas_schmidt on 3/18/2011 at 8:27 AM
I can't believe this is not yet fixed in SP1!!!

Posted by dvlg on 3/13/2011 at 5:41 PM
We need a solution for this! We are still working on VS 2005 and can't upgrade our project to 2010 due to this bug!
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...

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:
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 Eugen Klerner on 2/23/2011 at 6:32 AM
I ran in the same problem yesterday (Couldn't compile the project as x64). Today I figured out the problem was the ImageList.

To solve this problem I used the VS2008 to make the required design changes and saved the project. Then reopen it in VS2010, it works now.

However, it would be nice if this problem could be solved.
Posted by Alex Sorcinelli on 1/5/2011 at 2:26 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.
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 Jas001 on 12/8/2010 at 12:46 PM
I'm seeing the same error on other items in the resx as well. For example a Matrix was struck in there from one of my classes:
<data name="camera3DOrbitQuatSmooth1.OrbitTransform" mimetype="application/x-microsoft.net.object.binary.base64">
It says the error is on the close data tag. But, even if you remove this entire section it will start erroring on the imagelist as well.
Posted by Jas001 on 12/8/2010 at 12:39 PM
I ran into this issue when converting a 2008 project to 2010. It runs on my 32bit xp box and when I try and run the same project on windows 7 64 I get the error. You need to fix this!
Posted by Chris Glasser on 11/29/2010 at 11:59 AM
Yes, this bug is a real pain. I can't use Intellitrace because it requires the solution to be compiled as x86, and I can't compile as x86 because of this bug. So having Intellitrace as part of my high priced VIsual Studio Ultimate is useless because I can't use it.
Posted by Wupaz on 11/24/2010 at 7:55 AM
Yep fix that bug, it's last issue before we can upgrade to Windows 7 !
Posted by lynxpmwalt on 11/11/2010 at 3:10 PM
Please...please fix this soon.
Posted by Cook32 on 11/4/2010 at 9:00 AM
Whats new about this bug ??? It is really a pain !!
Posted by Steven Shacklette on 11/3/2010 at 9:26 AM
This really needs to be fixed. There is no excuse.
Posted by Julian - Videoswitch on 9/23/2010 at 10:45 AM
I imported a Visual Studio 2009 proyect, which runs on framework 3.5. To make any changes to a form Class that has an ImageList control, the project fails to compile. The error indicate that isn't a Win32 application!!!!!!

Microsoft planed a patch to this issue????

Posted by CloverCode on 9/13/2010 at 7:17 AM
Experiencing the same issue here. Microsoft, any update in the last two months?
Posted by GPT999 on 9/8/2010 at 3:17 PM
I just ran into this issue as well, I jumped to 2010 from 2005 on this porject and was excited to use it...Well that was short lived :-(

Hello Microsoft, how about a patch? The work-around manually changing the value in the resx file seems to work, what a pain!
Posted by ThomasJordan on 8/15/2010 at 5:23 AM
We just got hit by this. It has consumed an inordinate amount of time and still not resolved. Someone replaced an image and the build starting going down with this error pointing into the imagelist. We are just trying to build x86 project with .Net 3.5 in a 32 bit environment. We thought the imagelist might be corrupt and went as far as to rebuild the entire thing. None of the workarounds has worked only reverting backwards.
Posted by Webbbb on 8/12/2010 at 10:11 AM
Using some of the steps here we were able to get this somewhat working, only now it has a very unfortunate side affect. Every time one of our devs opens a winform, the resx is for some strage reason being modified, which causes a checkout to occur. Most of the time this goes unnoticed and since we have multiple checkout enabled in TFS (the default), we have completely lost the ability to meaningfully track who is actually modifying a winform. We're starting to lost faith in the Visual Studio team because of this.
Posted by Theo_plugwise on 7/26/2010 at 2:58 AM
Please note that #532584 is still closed and refers back to this report... It's an endless loop...
Posted by Microsoft on 7/25/2010 at 2:59 PM
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 bigstu80 on 7/21/2010 at 7:10 PM
We also have the same issue. We must compile using .NET 2.0 and in x86. But now we're getting these ImageList issues in VS2010. This was never an issue before. Why is this issue marked closed?!!
Posted by jimbeasley on 7/19/2010 at 4:16 PM
We are also encountering this error with a large project that was rebuilt using VS2010. This problem has already cost us a considerable amount of headache and time. Is there a fix here or not? (the workarounds mentioned above do not appear to work for us)
Posted by J. Clay on 6/9/2010 at 3:52 PM
I am getting this also, but was able to use Luis Mack's workaround as listed on the primary feedback item link above.
Posted by Philip Stears - DriveWorks on 5/21/2010 at 3:29 AM
We're getting this issue too - I can't understand why this issue has closed, it's clearly a bug in a Microsoft component. I can reproduce this by adding a reference to PIAs that aren't GACed as well as the other reproductions listed here.
Posted by mkchandler on 5/12/2010 at 11:43 AM
This bug should not be closed or marked as external. I do not use the Plugwise.Util.dll and I am able to reproduce this error using a standard .NET ImageList. I am using Visual Studio 2010 Ultimate RTM on Windows 7 Enterprise x64.
Posted by workandparty on 5/9/2010 at 6:56 AM
I don't understand how this bug can be marked as external, because I don't use Plugwise.Util.dll or any other external libraries.
Look into attached project. Any external libraries there? No?
Yes, if I build project as Any CPU there is no errors. But I need build project as x86. And I don't use any external libraries such as Plugwise.Util.dll or others. Only .NET framework libs.
Posted by Microsoft on 5/9/2010 at 1:22 AM
thanks very much for your feedback! this is actually a bug in Visual Studio 2010, which has been discussed at http://connect.microsoft.com/VisualStudio/feedback/details/532584/error-when-compiling-resx-file-seems-related-to-beta2-bug-5252020.

Copy the words from the link above:

<Words From the link>

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.

</Words From the link>

we would push to have this bug fixed.

Thanks very much for your feedback.
Posted by MarkLIC on 5/6/2010 at 10:16 AM
I was having an unbelievable amount of trouble finding the link to this report. I was having this same issue, and the error I was receiving was "A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A) Line 434, position 5", where the position was the closing tag of the ImageList's ImageStream in the resx file in question.

<data name="imageList1.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">

As a workaround, I was able to copy the original base64 data from a checkin before VS2010 modified it, into the newer data. But, whenever I view that form in Designer, VS tries to check out that file and modify it again.
Posted by Webbbb on 5/5/2010 at 2:27 PM
I have opened a support case with Microsoft and sent in a mini-version of our solution that reproduces this issue. Support case is REG:110050368668325
Posted by WickedDancer on 5/5/2010 at 2:12 PM
I hope that MS is looking into this. We haven't seen any comments from them since April 28th. Clearly this is a bug and it is affecting my ability to complete my project.
Posted by Jos G on 5/5/2010 at 9:24 AM
Same here. As soon as the resX file gets modified by VS 2010 I can no longer build. The only solution is to revert the resX file changes.
Posted by lstpierre on 4/30/2010 at 5:36 PM
I just ran in the same issues.. Hope Microsoft find a Workarround!!!
Posted by Webbbb on 4/30/2010 at 9:30 AM
We were able to reproduce this in our project also. This is very unfortunate as we've just converted our project to VS 2010, which took about a week, then we ran into this the first winform we changed. I think the only "workaround" is to port back to vs 2008, what a pain!
Posted by Microsoft on 4/28/2010 at 7:43 PM
Thank you for reporting this issue.
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 bnb on 4/28/2010 at 4:42 AM
The "Workaround" mentioned at similar Bugreports (e.g. https://connect.microsoft.com/VisualStudio/feedback/details/552658/vb-2010-solution-imported-from-vs-2008-invalid-format-in-resx-file) to Build in "Any CPU" Mode does not do the trick here.
Posted by bnb on 4/28/2010 at 4:40 AM
Same here. Recently converted a 3.5 Winforms Application from VS2008 to VS2010. As sonn as you change something in the Designer of a Form containing a ImageList, the underlying resx File fails to compile, giving a (false?) Message about a missing Assembly (which has nothing to do with the resx itself)
Posted by WickedDancer on 4/28/2010 at 1:58 AM
I just installed VS 2010 last week and have been encountering this exact issue with an ImageList loading from a .resx file. I have a bunch of forms that all inherit from the same base form which has the imagelist in it. These forms all have tabs. If I add a tab onto the derived form and refer to the base class imagelist for the image the set of images is then stored in the derived class' .resx file.

Somehow, this is getting corrupted. If I replace the XML sequence in the .RESX file with a previously saved one, then it is ok for a while but quickly gets corrupted again. This usually occurs after I've edited something unrelated in the forms designer.
Posted by Microsoft on 4/28/2010 at 1:38 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 sgissinger on 6/21/2012 at 3:13 PM
To complete Alberto De Luca's workaround, you can double-clicked on my MainWindows.resx file and deleted the imageList.ImageStream resource directly in the Resource editor (no need to go into XML). VS2010 SP1 didn't try to recreate it and compiles well.

Using project Resources is a relatively good workaround because of Resources check at runtime.

Here is a sample of code which uses project Resources that need to be added add in Form's constructor just after this.InitializeComponent() method call :


this.tabControl.ImageList = this.imageList;
this.tabPageSystem.ImageIndex = 0;
this.tabPageDivers.ImageIndex = 1;
Posted by Dawid van Zyl on 6/9/2011 at 8:55 AM
Read the following blog it solve the problem. But there are also some draw backs depending on what solution is chosen.

Posted by FredyLD on 6/3/2011 at 10:05 PM
Excuse about my English... In my project I had imagelists with ColorDepth in Depth8Bit, 24Bit and 32Bit. I changed all to 32Bit and re-added pictures. After that, everything worked well.
Posted by zarfius on 2/11/2011 at 6:49 PM
The way I get around this is to load the icons from code using embedded resources. You can add the images to your solution and set them to 'Embedded Resource' in the properties. Then for each image, you can do something like this in code.

imageList.Images.Add(new Bitmap(Assembly.GetExecutingAssembly().GetManifestResourceStream("ProjectName.SubFolder.imagename.png")));
Posted by Jas001 on 12/8/2010 at 1:37 PM
What I did was move all of the images that I was referencing into properties/resources instead of local resources and it recovered.
Posted by DanyR on 10/28/2010 at 4:32 AM
See also the tiny command line tool named Set2010ImageListsToNET2 in the file attachments, which takes a single resx or a path to be patched. You may freely use it and have a look at the source with Reflector.
Posted by DanyR on 10/28/2010 at 12:48 AM
The patch from Ed Hartley has the following internal effect:

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").

Please, please, please fix this ASAP.

Posted by Ed Hartley1 on 9/2/2010 at 4:56 PM
After editing the form search the resx for "j00L" on the first line of the imagelists block and change to "j0yL".
You have to do it everytime you make a change though.
Posted by Pierre-Alain Vigeant on 5/11/2010 at 8:32 AM
It required a lot of work, but we got rid of this error by using a 3rd party imagelist component. In our case, we used the DevExpress ImageCollection control.

The ImageList serialization is bugged, we won't be using it anymore.
Posted by MarkLIC on 5/6/2010 at 10:10 AM
As @jgeer said on the comments page, manually copying the content from the original resx's imagelist data to the current version works temporarily, but then Visual Studio tries to convert (and break) it again.
Posted by Alberto De Luca on 5/6/2010 at 6:36 AM
I have similar problem and then have bypassed. I place an empty ImageList in the form and then added the icons at runtime. Image source is the application resources... I know that's no good, but can be a temporary solution. I think the bug is in imagelist resource definition:
<data name="ImageList1.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">
if you try to change the mimetype attribute:
<data name="ilMain.ImageStream" mimetype="application/x-microsoft.net.object.bytearray.base64">
the project will be compiled but doesn't run.
Sorry for my English... I hope is understandable ;)
Alberto De Luca
File Name Submitted By Submitted On File Size  
WindowsFormsApplication5.zip (restricted) 4/27/2010 -
ImageListIssue.zip 5/21/2010 675 KB
Set2010ImageListsToNET2.zip 10/28/2010 5 KB