- Home /
CodePage 1252 not supported - works in editor but not in standalone player
I just ran across this very nasty issue and thought I'd share it here for the record - answer coming in a minute ;-)
My game server which accesses a MS SQL Server database and uses System.Data.dll worked fine in the Unity editor but gave me nasty exceptions when trying to run as standalone:
System.NotSupportedException: CodePage 1252 not supported
at System.Text.Encoding.GetEncoding (Int32 codepage) [0x00000] in <filename unknown>:0
at Mono.Data.Tds.TdsCharset.GetEncodingFromLCID (Int32 lcid) [0x00000] in <filename unknown>:0
at Mono.Data.Tds.TdsCharset.GetEncodingFromLCID (System.Byte[] collation) [0x00000] in <filename unknown>:0
at Mono.Data.Tds.TdsCharset.GetEncoding (System.Byte[] collation) [0x00000] in <filename unknown>:0
And later:
System.NullReferenceException: Object reference not set to an instance of an object
at Mono.Data.Tds.Protocol.TdsConnectionPool.GetConnection () [0x00000] in <filename unknown>:0
at System.Data.SqlClient.SqlConnection.Open () [0x00000] in <filename unknown>:0
What's the problem?
Almost 6 years later : Thanks dude :)
I got an asignment for tomorow and just had this issue.
Answer by jashan · Jan 14, 2011 at 10:55 PM
The issue here is that I18N.dll and I18N.West.dll are missing in the standalone player. They are available in the editor, though. That's why it's working in the editor but not in the standalone player.
Solution: Put those DLLs into your project (probably best next to System.Data.dll), that way, they will be also available in the standalone player.
You find those DLLs on the Mac in:
Unity ("Show Package Contents") / Contents/Frameworks/Mono/lib/mono/unity
And under Windows in:
C:\Programme\Unity\Editor\Data\Mono\lib\mono\unity
"Programme" might be "Program Files" for you ;-)
NOTE: There's also other I18N ("Internationalization") DLLs available, so if you have trouble with another CodePage, you might have to use one of those in your specific case.
Wow. I just ran into this also and your answer worked for me right off the bat. Hard to imagine how much time your answer probably saved me.
Thank you!!!!!
Barry
Hm, the "next to System.Data.dll" doesn't make sense to me, as I don't see that anywhere in my project (or its folder tree). It's there in the build, but that would mean to always remember to copy the I18-dll's into that after every build, which is extremely error prone.
I solved it for me by copying these into the project's Assets/Plugins folder, as @Cat Burton suggested.
Thanks!
Answer by lizardboy79 · Apr 07, 2015 at 09:37 PM
Hey all,
there is a much better solution than copying DLLs. When you do your serialization, make sure to use a Streamwriter with encoding set to "UTF-8" rather than a FileStream. Like this:
var serializer = new XmlSerializer(typeof(SerializableClass));
string filename = Application.dataPath + outputpath + outPutFileName;
var encoding = Encoding.GetEncoding("UTF-8");
using(StreamWriter stream = new StreamWriter( filename, false, encoding))
{
serializer.Serialize(stream, this);
}
NOT:
using(var stream = new FileStream( Application.dataPath + outputpath + outPutFileName, FileMode.Create))
{
serializer.Serialize(stream, this);
}
No more errors. Cheers!
Also worked for me. I like this solution better. Especially since I got this problem on Android, and UTF-8 is definitely what I'd want.
Thanks to you both. jashan for bringing up the topic and lizardboy79 for the more elegant solution.
This only works if you can use the StreamReader/StreamWriter. If you're using something like SharpZipLib that only takes streams or filenames and not StreamReaders, then you're out of luck
Answer by cpuvpubp · Mar 20, 2016 at 04:25 PM
Thanks dude i fixed my mysql connection problems after build with this method
Answer by catburton · Jul 19, 2012 at 02:04 PM
Regarding the same situation but for iOS - Putting the DLLs in Assets/Plugins and referencing them from your script should ensure those dll's are included in the build. If when building for iOS you still encounter issues with the DLLs, check your stripping level to ensure the code is not being removed as part of build optimisations:
http://docs.unity3d.com/Documentation/Manual/iphone-playerSizeOptimization.html
Copying the DLLs works for my windows build, but breaks my WebGL build of the same project.
Answer by sk8er8921 · Jul 12, 2016 at 08:08 AM
Copying the .dll's definitely worked but I also had to change the scripting backend in player settings from IL2CPP to Mono2x. I didn't see this mentioned here and it worked for me, so hopefully this helps someone.
The same here. I have to use $$anonymous$$ono ins$$anonymous$$d of IL2CPP for some reason...