Hey, got this error whenever editing my mntp's that has been imported from an old site.
Server Error in '/' Application.
Input string was not in a correct format.
Description: An unhandled exception occurred during
the execution of the current web request. Please review the stack trace
for more information about the error and where it originated in the
code.
Exception Details: System.FormatException: Input string was not in a correct format.
Source Error:
An unhandled exception was generated during the execution of the current
web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272
From old experiences it could very well be the sort order of the prevalues wich is f****. Belive it's something about them being cool when created by API, but all sort order 0 when edited via interface. Dunno if it's totally correct, but has heard some stuff like that lately :-)
Not sure if something has changed in uComponents between versions, the buggy XML contains one more prevalue and works if you remove the top prevalue
<PreValue Id="58" Value="0"/>
Not sure how that's been created, might be a different version of uComponents had a different set of prevalues ? and when the new version reads the file it is expecting it in a different order?
the MultiNodeTreePicker in umbraco and the one in the last few versions of uComponents all expect TreeType "Content"/"Media" to be the first value, I can't go back far enough to see when this changed - it would be good to now what version the old MNTP is in ?
I've done a similar tool to enable our continuous integration flow to run more smoothly. And I ran into the exact same problem with the MNTP prevalues.
I haven't had a look at your code, but I can tell from your XML format that you're doing much the same as I am when importing data types.
The bad XML has had a prevalue added as the first prevalue (ID 58, value "0") and it's missing the prevalue with ID 70 (value "") from the working XML. This used to happen in my tool as well, and what I found puzzled me: For some reason, the sort order of prevalues is overwritten when creating or updating datatypes using the backoffice. Since the datatypes are relying solely on the order of the prevalues when initializing the backoffice, this is kind of silly; this means that the order in which the prevalues are written to the database (their primary key) determines the order in which they are passed to the datatypes.
Again I'm guessing here since I haven't seen your code. But my guess would be that you import the datatype prevalues in the order they're written to the XML file. So you need to be absolutely sure you're writing them in the correct order. Since we obviously need to take sortorder into account (in case it should actually work) and also need to use the primary key ID for sorting, I'd do something like this when exporting prevalues:
On a side note, you might want to use the built in import/export support for datatypes if you're not doing so already (and if I read your XML correctly you might not be). Have a look at
DataTypeDefinition.ToXml(XmlDocument xd)
DataTypeDefinition.Import(XmlNode xmlData)
For creating datatypes that do not exist in the target database, this should probably be your preferred solution.
Oh - and please note that everything I just wrote has only been tested on version 4 (but it works on all versions form 4.7 through 4.11.x).
yes uSync uses ToXML and Import at every opertunity (i am a lazy dev) - However for DataTypes is doesn't actually use the Import function because the one in the Core doesn't work when called for an ApplicationStartupHander event (others do - one of the core's little quirks).
yea it gets them in sort order but not also id order :( oh well. I'm basically just going to copy the umbraco ToXML and add the your line above. but it's always good to have an extra pair of eyes on the code. :)
....hmmm sorry but it looks like it's still not working as intended in 1.2.0.
I had my colleague test it out and the same thing happened; the MTNP was imported correctly on the target site, but as soon as it was accessed and saved, the prevalues messed up and caused a YSOD.
This time I was there to look him over the shoulder and after trying back and forth a few times without luck I went to have a look at the database. And I think I've found the error.
Obviously, the original prevalue with ID 61 is the one missing from the exported XML and has been replaced with the prevalue with ID 211.
When looking into the cmsDataTypePreValues table after importing the MNTP (and before accessing it), sure enough the prevalues table contains all the prevalues from the import XML except the empty prevalue with ID 61. Could it be that you're removing empty prevalues before importing?
ahh yes, don't you hate it when that happens, being to clever for my own good with String.IsNullorEmpty - I can now recreate and have a fix for the above - uncovered an onDelete change in 6.0.4 as well : ) - just packaging up and testing on a few versions of umbraco now.
v.6.0.4 MNTP issue
Hey, got this error whenever editing my mntp's that has been imported from an old site.
Server Error in '/' Application.
Input string was not in a correct format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.Exception Details: System.FormatException: Input string was not in a correct format.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272
From old experiences it could very well be the sort order of the prevalues wich is f****. Belive it's something about them being cool when created by API, but all sort order 0 when edited via interface. Dunno if it's totally correct, but has heard some stuff like that lately :-)
Hope it can be solved :-)
Working XML:
Buggy XML on a MNTP
Not sure if something has changed in uComponents between versions, the buggy XML contains one more prevalue and works if you remove the top prevalue
Not sure how that's been created, might be a different version of uComponents had a different set of prevalues ? and when the new version reads the file it is expecting it in a different order?
the MultiNodeTreePicker in umbraco and the one in the last few versions of uComponents all expect TreeType "Content"/"Media" to be the first value, I can't go back far enough to see when this changed - it would be good to now what version the old MNTP is in ?
Hmmm best stick my nose in here :)
I've done a similar tool to enable our continuous integration flow to run more smoothly. And I ran into the exact same problem with the MNTP prevalues.
I haven't had a look at your code, but I can tell from your XML format that you're doing much the same as I am when importing data types.
The bad XML has had a prevalue added as the first prevalue (ID 58, value "0") and it's missing the prevalue with ID 70 (value "") from the working XML. This used to happen in my tool as well, and what I found puzzled me: For some reason, the sort order of prevalues is overwritten when creating or updating datatypes using the backoffice. Since the datatypes are relying solely on the order of the prevalues when initializing the backoffice, this is kind of silly; this means that the order in which the prevalues are written to the database (their primary key) determines the order in which they are passed to the datatypes.
Again I'm guessing here since I haven't seen your code. But my guess would be that you import the datatype prevalues in the order they're written to the XML file. So you need to be absolutely sure you're writing them in the correct order. Since we obviously need to take sortorder into account (in case it should actually work) and also need to use the primary key ID for sorting, I'd do something like this when exporting prevalues:
On a side note, you might want to use the built in import/export support for datatypes if you're not doing so already (and if I read your XML correctly you might not be). Have a look at
For creating datatypes that do not exist in the target database, this should probably be your preferred solution.
Oh - and please note that everything I just wrote has only been tested on version 4 (but it works on all versions form 4.7 through 4.11.x).
Regards,
Kenn
yes uSync uses ToXML and Import at every opertunity (i am a lazy dev) - However for DataTypes is doesn't actually use the Import function because the one in the Core doesn't work when called for an ApplicationStartupHander event (others do - one of the core's little quirks).
Looking at the ToXML function in DataTypeDefinition (http://umbraco.codeplex.com/SourceControl/changeset/view/b03c1fb77762#src/umbraco.cms/businesslogic/datatype/DataTypeDefinition.cs) it doesn't attempt to get them in sort order - so i will probibly end up writing my own one of them too : (
If i can reproduce this error using the Package Create / Import in Umbraco i will log it on issues.umbraco.org
It actually does attempt to get them in sort order - PreValues.GetPreValues() does sort by sortorder (http://umbraco.codeplex.com/SourceControl/changeset/view/b03c1fb77762#src/umbraco.cms/businesslogic/datatype/PreValues.cs) - but if they're all zero'd it doesn't help much.
Let me know if you need any help reviewing or fixing this issue for your importer.
yea it gets them in sort order but not also id order :( oh well. I'm basically just going to copy the umbraco ToXML and add the your line above. but it's always good to have an extra pair of eyes on the code. :)
new version (1.2.0) of uSync is now on this site and attempts to save values in id order - this should fix this issue.
Cool, I hope you could use my input :)
I haven't tested it, but I hear one of my colleagues is going to.
....hmmm sorry but it looks like it's still not working as intended in 1.2.0.
I had my colleague test it out and the same thing happened; the MTNP was imported correctly on the target site, but as soon as it was accessed and saved, the prevalues messed up and caused a YSOD.
This time I was there to look him over the shoulder and after trying back and forth a few times without luck I went to have a look at the database. And I think I've found the error.
The XML being imported looks like this:
After accessing the imported MNTP, the exported XML looks like this:
Obviously, the original prevalue with ID 61 is the one missing from the exported XML and has been replaced with the prevalue with ID 211.
When looking into the cmsDataTypePreValues table after importing the MNTP (and before accessing it), sure enough the prevalues table contains all the prevalues from the import XML except the empty prevalue with ID 61. Could it be that you're removing empty prevalues before importing?
Regards,
Kenn
ahh yes, don't you hate it when that happens, being to clever for my own good with String.IsNullorEmpty - I can now recreate and have a fix for the above - uncovered an onDelete change in 6.0.4 as well : ) - just packaging up and testing on a few versions of umbraco now.
Kevin
Hehe yes.... I hate it when that happens :)
OK uSync 1.2.1 appears to work, on Umbraco 6.0.4 and 4.11.x for this issue, appreciate it if you could try and see if it fixes your problems.
Hey Kevin,
I'll have my colleague test it as soon as possible - probably not today but hopefully tomorrow.
-Kenn
Hey Kevin,
Works like a charm :-)
Cheers, #h5yr
is working on a reply...