We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Resource transformation for file ''somefileorother.resx'' failed

Thread ID:

Created:

Updated:

Platform:

Replies:

41249 Feb 25,2006 10:58 PM UTC Feb 28,2006 09:42 PM UTC General Discussion 14
loading
Tags: General Discussion
Administrator [Syncfusion]
Asked On February 25, 2006 10:58 PM UTC

i''m trying to migrate a large project from 2.0.5.1 to 4.1.0.50 i ran the convert tool but get the following when i compile the project... what am i doing wrong??? somefileorother.resx: Resource transformation for file ''somefileorother.resx'' failed. Exception has been thrown by the target of an invocation. btw i auto updated the refs in the csproj files via a program rather than manually removing and adding...

Administrator [Syncfusion]
Replied On February 25, 2006 11:20 PM UTC

so if i dont hand edit the csproj''s but do it the manual way of removing then re-adding the refs then this problem doesn''t happen... i really dont want to have to do it this way we have a lot of projects to convert :-( i cant understand why syncfusion haven''t provided proper migration tools the convert resx is buggy and a pain to use also...

Administrator [Syncfusion]
Replied On February 25, 2006 11:33 PM UTC

Hi Pete, the convertresx is the "regenresx" tool from gotdotnet.com. We just added a UI to it and support for our libraries. There should be no reason to not be able to manually manipulate your .csproj. What you should do is compare the .csproj that is generated when you add references with visual studio with the .csproj that you manually modified. If you do a windiff it will show the differences between the two variants and might give you an idea if you missed a step when manually converting the .csproj. You also only need to run the convertresx tool for those resx files that fail to compile. The others should be fine the way they are. Stefan >so if i dont hand edit the csproj''s > >but do it the manual way of removing then re-adding the refs then this problem doesn''t happen... > >i really dont want to have to do it this way we have a lot of projects to convert :-( > >i cant understand why syncfusion haven''t provided proper migration tools > >the convert resx is buggy and a pain to use also...

Administrator [Syncfusion]
Replied On February 26, 2006 10:40 AM UTC

so i am confused, I thought this tool was to convert old 2.0.5.1 reource issues to the new styles. If it doesn''t do this how are we supposed to migrate from one version to the next... for example in the new col width are done by this.gridControl1.ColWidthEntries.AddRange(new Syncfusion.Windows.Forms.Grid.GridColWidth[] { new Syncfusion.Windows.Forms.Grid.GridColWidth(0, 35), new Syncfusion.Windows.Forms.Grid.GridColWidth(1, 200), new Syncfusion.Windows.Forms.Grid.GridColWidth(2, 133), new Syncfusion.Windows.Forms.Grid.GridColWidth(3, 4)}); and in the old this.gridControl1.ColWidths = ((Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer)(resources.GetObject("gridControl1.ColWidths")));

Administrator [Syncfusion]
Replied On February 26, 2006 01:03 PM UTC

Hi Pete, there is no automatic conversion for this code. The grid will still be able to read the old resources (backward compatible) but if you edit (or click the touch it button) in the forms designer the next time the windows forms designer generates code it will write it in the new format. (BTW - You can also control whether cells should be written as CodeDom statements or serialized into the resx with the GridControl.SerializeCellsBehavior Property. Just a side note here ...) With version 4.x we made sure that going forward there should also be no issues anymore that need coverting the resx. What the conversion tool does is look for any assembly references that have a version number in them and then replaces them with version independent references. With previous grid versions some types were writing out the version number into the binary serialized resx format and that caused trouble then when converting to newer versions. The ColWidths and ColHidden collections were writing out version information. So it is good you run the resx tool in that case. Stefan >so i am confused, I thought this tool was to convert old 2.0.5.1 reource issues to the new styles. > >If it doesn''t do this how are we supposed to migrate from one version to the next... > >for example in the new col width are done by > > this.gridControl1.ColWidthEntries.AddRange(new Syncfusion.Windows.Forms.Grid.GridColWidth[] { > new Syncfusion.Windows.Forms.Grid.GridColWidth(0, 35), > new Syncfusion.Windows.Forms.Grid.GridColWidth(1, 200), > new Syncfusion.Windows.Forms.Grid.GridColWidth(2, 133), > new Syncfusion.Windows.Forms.Grid.GridColWidth(3, 4)}); > > >and in the old > > this.gridControl1.ColWidths = ((Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer)(resources.GetObject("gridControl1.ColWidths"))); >

Administrator [Syncfusion]
Replied On February 26, 2006 01:54 PM UTC

doesn''t seem to be backward compatable?? the widths resource now has this erialized type:- "Syncfusion.Windows.Forms.Grid.GridModelColWidthsIndexer" but of course the old code is lokking for Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer so what goes on???

Administrator [Syncfusion]
Replied On February 26, 2006 04:44 PM UTC

Hi Pete, The grid still fully understands and still uses GridModelRowColSizeIndexer. It only has set the DesignerSerialization attribute to be hidden so that when code gets written out to CodeDom it writes out the the contents of GridModelColWidthsIndexer instead. GridModelColWidthsIndexer is just a wrapper around GridModelRowColSizeIndexer that implements a strong-typed collection in such a way that it can be serialized to code and read back from. At runtime you still access and modify GridModelColWidthsIndexer as before. And when it is read from a resx there is no change to earlier versions. Only with the newer version when writing it out the wrapper comes into place and writes the contents into the CodeDOM. And when it reads it back it creates the GridModelRowColSizeIndexer from the contents of the CodeDom. So the grid can still load the content from resx (GridModelRowColSizeIndexer) if it is in old format or from CodeDom (GridModelColWidthsIndexer) when it is in new format. GridModelColWidthsIndexer is just a helper class to make CodeDom serialization possible. Stefan >doesn''t seem to be backward compatable?? > >the widths resource now has this erialized type:- >"Syncfusion.Windows.Forms.Grid.GridModelColWidthsIndexer" > >but of course the old code is lokking for > >Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer > >so what goes on???

Administrator [Syncfusion]
Replied On February 26, 2006 05:50 PM UTC

the problem is that the code throws an exception as it''s trying to cast the returned widths object i see this both in design mode and in runtime... thats why i noticed it...

Administrator [Syncfusion]
Replied On February 26, 2006 05:56 PM UTC

heres the line that will cause problems this.gridControl1.ColWidths = ((Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer)(resources.GetObject("gridControl1.ColWidths"))); but after the conversion we get a diffrent object in the binary serialise ie . Syncfusion.Windows.Forms.Grid.GridModelColWidthsIndexer and so the cast fails...

Administrator [Syncfusion]
Replied On February 27, 2006 01:09 AM UTC

Hi Pete, this is odd and should not happen. The convertresx tool does not change types within the resx. And the form when it is modified should not write out a GridModelColWidthsIndexer type into the resx. That type should only be serialized into code. We will create a sample tomorrow and walk through / double-check that conversion process to see if we can reproduce the problem you describe. Stefan >heres the line that will cause problems > this.gridControl1.ColWidths = ((Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer)(resources.GetObject("gridControl1.ColWidths"))); > >but after the conversion we get a diffrent object in the binary serialise ie . Syncfusion.Windows.Forms.Grid.GridModelColWidthsIndexer > >and so the cast fails...

Administrator [Syncfusion]
Replied On February 27, 2006 02:24 PM UTC

Pete, attached find a sample that walks through the steps for converting the sample. Can you try that sample and check if you also run into issues with that sample if you follow the steps on your system? ResxUtility.zip If this sample works for you then I would think it works in general and something odd happened with your app and I recommend to start again from the original you had and give it another try. Thanks, Stefan >Hi Pete, > >this is odd and should not happen. The convertresx tool does not change types within the resx. And the form when it is modified should not write out a GridModelColWidthsIndexer type into the resx. That type should only be serialized into code. > >We will create a sample tomorrow and walk through / double-check that conversion process to see if we can reproduce the problem you describe. > >Stefan > >>heres the line that will cause problems >> this.gridControl1.ColWidths = ((Syncfusion.Windows.Forms.Grid.GridModelRowColSizeIndexer)(resources.GetObject("gridControl1.ColWidths"))); >> >>but after the conversion we get a diffrent object in the binary serialise ie . Syncfusion.Windows.Forms.Grid.GridModelColWidthsIndexer >> >>and so the cast fails...

Administrator [Syncfusion]
Replied On February 27, 2006 10:35 PM UTC

sorry to be a pain... but we dont want to ahve to do this manually we have a large number of dialogs and so going through ''touching'' them will be a real pain

Administrator [Syncfusion]
Replied On February 28, 2006 03:21 AM UTC

Hi Pete, there is no need to "touch" them. Just running ConvertResX will make sure they open up just fine with 4.x and future versions. As mentioned before the forms are backward compatible and if you do not change them then the column widths will be loaded from the resx just as they did with earlier versions. The step is mentioned in the sample only since we tried to reproduce the error you described. Stefan >sorry to be a pain... > >but we dont want to ahve to do this manually > >we have a large number of dialogs and so going through ''touching'' them will be a real >pain > >

Administrator [Syncfusion]
Replied On February 28, 2006 10:26 AM UTC

again... i dont understand as when i used the convert it seemd to change the type thats in the resx ina binary serializiation this does not match the type in the code

Administrator [Syncfusion]
Replied On February 28, 2006 09:42 PM UTC

Pete, can you upload your project? Then we can run convertresx here and see if it converts fine and if there are problems debug into it. ConvertResx itsself has no knowledge about the Form. It can only replace the version number and assembly name of types within the resx. Stefan >again... > >i dont understand as when i used the convert it seemd to change the type thats in the resx ina binary serializiation > >this does not match the type in the code

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

;