How MSBuild could make a file inparseable

Problem: A text file that was being parsed from an assembly being part of a developing system. In the developer environment, this worked great. After having deployed the text file and the necessary assemblies to a different location using MSBuild, where MSBuild also replaced a couple of strings inside the text file, parsing would no longer work.

• Looking at the file in a text editor (i use Notepad++) confirmed that the edited version looked fine.
• Editing the file in the developer environment manually (not running MSBuild on it) worked fine - the file was parseable afterwards.

Obviously, MSBuild made the file inparseable So how could MSBuild make the text file inparseable? The command touching the file was

<MSBuild.ExtensionPack.FileSystem.File 
     TaskAction="Replace" 
     RegExPattern="Something" Replacement="SomethingElse"
     Files="%(filename)"/>

Only when tracing the code parsing the file it became clear to me that the file now contained some extra characters at the beginning of the file. Then it occurred to me:

Solution: MSBuild changed the file encoding. To make sure MSBuild used the right encoding, I had to add one more key/value pair to the MSBuild tag mentioned above:

TextEncoding="Windows-1252"

I found this by inspecting the file encoding on the source and destination text files. My source file was reported as ANSI, whileas my destination file was reported as UTF-8. It was however not as simple as putting "ANSI" as the TextEncoding, as described in this excellent StackOverflow article, which also lead me on the right path to "Windows-1252".

In my opinion, MSBuild should have retained the original encoding on the files it touches instead of  defaulting it into something unwanted. But then again, that's wat keeps bread on my table... Thanks, MS...

Failing Office automation when run from a service

Scenario: I needed to create a small script to automate the conversion of a Word document into PDF. There's plenty of help out there to script this by using the Microsoft.Office.Interop namespace, for example this simple one. I tried both writing a Powershell script and a compiled C# .exe with the same result: When running from the desktop, everything works fine, whileas running from a scheduled task or from CruiseControl running as a system service failed. If CruiseControl was running from its debug console window however, everything ran fine.

Problem: It seemed clear that the Office libraries required a logged on session to run in, as  also Microsoft confirms here in their Q257757 article.

Solution/workaround: I came across this hack - reposting it here for my own easy access to the knowledge:

1. Browse to or create this folder: C:\Windows\SysWOW64\config\systemprofile\Desktop on 64 bits Win7/Win2008 - for 32-bits Windows, substitute SysWOW64 part of the path with System32. You might have to change some permissions to get there and you of course need to have administrative rights.
2. Make sure the user credentials running the service or scheduled task you want to use has full control access permissions to the folder.

I have no idea how this trick can make it all work, but it does - at least in my case. Since Microsoft does not recommend or describe it however - use solely at your own risk. Not suitable for rocket launchers, weapon systems etc..

PHP scripts stopped working when moved

Problem: After having moved some PHP scripts from one web server to another, they stopped working , or only worked partially. One of the webpages showed all the HTML and the upper part of PHP generated code, but strangely after a certain point the rest of the PHP code had just been ignored.

Solution: I loaded one of the script files in the open source DevPHP editor and chose Format on the menu. The Mac (CR) option was checked. I changed it to Windows (CRLF), uploaded the file again and reran it. Voilla, it worked!

Obviously, some PHP parsers may be more picky than others with how they read line breaks.

Edit and display local characters in .bat scripts

Problem: Sometimes I need to write a batch script echoing instructions in my native language Norwegian, including its special characters æ, ø and å. The only thing is, if you edit the .bat or .cmd file in Notepad, it will translate into garbled characters because of an character encoding issue.

Solution: With my favorite plain text editor, the free Notepad++, I have the possibility of selecting encoding for the file I am editing. Menu item Encoding-Character sets-Western European-OEM 850 works well for the Norwegian special characters, and possibly others.

VB.NET: Shell32 code compiled on Vista does not run on XP/2003

This was a tricky one, and I had a hard time finding a working solution. I finally found the solution by reading comments in differnt forum. I had to mix it together myself - here's the finished soup:

Situation: I had a VB.NET code that was based on VBscript code from "Hey, scripting guy" to programmatically pin shortcuts from the desktop onto the start menu. This line of code created a bit of a headache:

Dim oShell As Shell32.Shell = New Shell32.Shell
Dim oFolder As Shell32.Folder = oShell.NameSpace(0) '0 refers to user desktop

Problem: The code compiled and ran on my Vista computer, but once I moved the .exe file to a Server 2003 computer, it threw a runtime exception stating: Unable to cast COM object of type 'Shell32.ShellClass' to interface type 'Shell32.IShellDispatch5 and then the usual garble (actually, the garble did reveal the line of code in question)

Cause: The Shell32 library comes in a new version in Vista compared to XP/2003 - or that is my conception of what I could find on the subject. The problem is that under XP/2003, the Shell32.ShellClass is not casted to Shell32.IShellDispatch5, but to its predecessor, Shell32.IShellDispatch4. Now I knew the difference, but it meant that the program needs to reference the right one.

Solution: I found the two first lines of code below buried in a comment in a forum - when they replace the first line of code above, voilla: It works on all platforms (the term 'all' referring to XP, Server 2003 and Vista):

Dim ShellAppType As Type = Type.GetTypeFromProgID("Shell.Application")
Dim oShell As Object = Activator.CreateInstance(ShellAppType)
Dim oFolder As Shell32.Folder = oShell.NameSpace(0) '0 refers to user desktop

Nerds like me may be simple to please - it certainly made my day!