Only it's on xslt files - and it happens when I copy my xslt file to inetpub/site/xslt with robocopy in a VS2010 after build event.
Steps to reproduce
Edit xslt file in VS, copy from development dir to the web site xslt dir
Run page with xslt rendered from macro -> Error in xslt compilation
Open file in Umbraco backend and save
Run page again -> NO error in xslt compilation
Also keeping the deployed file open in Notepad++ I noticed notepad++ reports file as having DOS/Windows line endings and UTF-8 encoding after copying from vs dir, and it changes is to UNIX line endings / ANSI encoding when saving in Umbraco backend. web.config has response/request encoding set to UTF-8. The xslt file has encoding="utf-8" in xml declaration
For the record, are you using xcopy or robocopy now? I have never tried xcopy but I don't have this issue when using robocopy so it could be something specific to xcopy.
I just tried overwriting the file in my VS project with the file from the site, after saving the file in the Umbraco backend.
Now when I change the file in VS2010, and copy the file from VS project to Site folder, the problem goes away.
I'm pretty sure it's due to a mismatch between encodings and line endings in my original VS2010 file and what Umbraco saves as.
What really bugs me is that Notepad++ reports that saving the file in the backend changes encoding from UTF-8 to ANSI, and line endings from DOS/Windows to UNIX. If that's true it's a really odd behavior considering it's running on a windows box, and the xslt's xml header states it should be UTF-8 encoded.
Just to rule out one piece of the equation - the encoding="utf-8" pseudo-attribute in the XML only acts as a hint to the parser - it doesn't dictate anything to any tool, whatsoever.
My guess would be that the server has some kind of setting that states which encoding to save.
Yes I was thinking about the server settings also, that's why I checked web.config response/request settings (UTF-8). Don't know anywhere else to look.
I haven't ruled out Umbraco though, partly because Mike Taylor has a similar experience in the problem described above, partly because it looks like Umbraco i changing the encoding of the actual xslt file when saving from the backend.
I can copy the file from VS2010 project folder to \inetpub\site\xslt, then open the file with Notepad++ seeing it's UTF8, then open the file in Umbraco backend, save it and check back in notepad++ now its ANSI encoded.
Compile error on xslt after xcopy deployment
I have a problem resembling this one:
http://our.umbraco.org/forum/templating/templates-and-document-types/12692-Master-page-weirdness-after-xcopy-from-Web-Application-Project
Only it's on xslt files - and it happens when I copy my xslt file to inetpub/site/xslt with robocopy in a VS2010 after build event.
Steps to reproduce
For the record, are you using xcopy or robocopy now? I have never tried xcopy but I don't have this issue when using robocopy so it could be something specific to xcopy.
I'm using robocopy.
I just tried overwriting the file in my VS project with the file from the site, after saving the file in the Umbraco backend.
Now when I change the file in VS2010, and copy the file from VS project to Site folder, the problem goes away.
I'm pretty sure it's due to a mismatch between encodings and line endings in my original VS2010 file and what Umbraco saves as.
What really bugs me is that Notepad++ reports that saving the file in the backend changes encoding from UTF-8 to ANSI, and line endings from DOS/Windows to UNIX. If that's true it's a really odd behavior considering it's running on a windows box, and the xslt's xml header states it should be UTF-8 encoded.
Regards
Jesper Hauge
Just to rule out one piece of the equation - the encoding="utf-8" pseudo-attribute in the XML only acts as a hint to the parser - it doesn't dictate anything to any tool, whatsoever.
My guess would be that the server has some kind of setting that states which encoding to save.
(I know I'm not helping a lot :-)
/Chriztian
Any help is appreciated :)
Yes I was thinking about the server settings also, that's why I checked web.config response/request settings (UTF-8). Don't know anywhere else to look.
I haven't ruled out Umbraco though, partly because Mike Taylor has a similar experience in the problem described above, partly because it looks like Umbraco i changing the encoding of the actual xslt file when saving from the backend.
Regards
Jesper
Is there any FTPing going on anywhere? I know that FTP programs mess with content encoding sometimes.
No - it's all happening on my local machine.
I can copy the file from VS2010 project folder to \inetpub\site\xslt, then open the file with Notepad++ seeing it's UTF8, then open the file in Umbraco backend, save it and check back in notepad++ now its ANSI encoded.
Regards
Jesper Hauge
is working on a reply...