Friday, December 20, 2013

Visual Studio Solution dependent code sections

If you have a Visual Studio project that is part of several solution files (which in most cases is a bad practice - if conditions allow it, rather build a DLL that could be referenced from any solution), you may want to implement solution specific code fragments. In my case, I had a COM interface class that needed to specify a unique CLSID in its IMPLEMENT_OLECREATE call.

The solution: Create a solution specific preprocessor directive. This has been tested in C++ on VS2010:
  1. Define the parameter SOLUTION_$(SolutionName) in Project properties - Configuration Properties - C/C++ - Preprocessor - Preprocessor definitions. Note that the term $(SolutionName) should be written exactly as you see it here - these are MsBuild style variables.
  2. Now in your code, add #ifdef sections checking for the solution name.
  3. If you need to render an error in case none of the solution names defined are found, include a #define SOLUTION_FOUND inside each of your sections and check that it is defined afterwards. If not generate an #error to stop the compiler.
The code will look something like:

#ifdef SOLUTION_MySolutionName1
     (some code specific to that solution)
     #define SOLUTION_FOUND
#ifdef SOLUTION_MySolutionName2
     (some code specific to that solution)
     #define SOLUTION_FOUND
     #error None of the defined solutions were found. Build can not continue.

Wednesday, December 11, 2013

Source files missing from project, but still there (Linking error)

Situation: Some .cpp and .h files shared between several Visual Studio Project files in different VS solutions (I know - bad practice, but it was not my idea and I could not change it) were being relocated to a separate directory beside the solution dir of the project I was working on. By unloading the project in VS, then manually editing the .vcxproj file, it was a simple task to search and replace string entries like:

     ClCompile Include="folder\
     ClCompile Include="($SolutionDir)..\folder 

Since the job involved much more reorganizing, and there was a lot of other files in the project as well, it was not unexpected that several referencing and linker errors occurred along the way. 

Symptom: In the end I was faced with a linker problem I was not able to get rid of. LNK2001 and LNK2019 errors were filling my screen. I diffed the old and the new .vcxproj files to search for what I had lost along the way, but found no apparent problem at first. Not until I closely examined what reference the linker could not find, making sure that both a header entry and an implementation body (usually in a corresponding .cpp file) were actually present in the project. Somehow some of the files were not!

Problem: It turns out that for file references, the .vcxproj file simply ignores files written with MsBuild variable references like my ($SolutionDir)..\folder\file.cpp -They show up when you view the .vcxproj file in a text editor, but not from within Solution Explorer. Update: Seems like the MsBuild variable actually sometimes works (see the strikeout above), but not in the combination with double dots for jumping one step up in the folder hierarchy. Needs verification what conditions are for this problem to occur.

Solution: Once I had replaced the ($SolutionDir)..\folder entries in the .vcxproj file with the more boring and less flexible ..\..\folder, everything was fine.

Monday, November 25, 2013

Perforce: Translation of file content failed

This error practically introduced me to the Perforce version control system, and had no obvious explanation:

Scenario: I wanted to create a view of an existing file hierarchy containing many files on my local hard drive. As a part of the procedure, I executed the "Get latest revision". All but two files were transferred from the Perforce server, but two of the files logged the error "Translation of file content failed near line X". The file was missing when I looked at the physical location I was populating.

As many entries on the web mentions, encoding was the problem, but there are two places in P4V to set encoding - under Tools-Administration under Connections (which did not cut it for me), and:

Solution: Go to Connection-Choose Character Encoding and select the correct encoding.

I found the correct encoding by checking with a colleague who had it working. Otherwise: Trial and error will get you there (slowly).

Thursday, October 31, 2013

Backslash i Cord på norsk Mac

(How to get a backslash in Cord on a Mac with a norwegian keyboard layout - in Norwegian)

Tasten til høyre for ?-tasten gir deg backslash på norsk Mac.

Den kan iflg. mange nettfora nås via Alt-Shift-/ eller Alt-Shift-7, men dette fungerer ikke i fjernstyringsverktøyet Cord. I Cord er ofte backslash nødvendig for å få logget på et domene når man fjernstyrer en Windows-PC (man må typisk skrive domenenavn\brukernavn)

Sunday, October 6, 2013

Converting physical computer to virtual: Bluescreen

I have finally taken the leap and upgraded my trusty but painstakingly slow Windows Vista computer to Windows 8. I wanted to do a fresh install, but it is always nice to have a path back to using the old OS in case something goes wrong with the new installation. What better choice than doing a conversion of the physical Vista computer to a virtual one (a P2V)!

The free VMware vCenter Converter specializes in just that - it is an easy download and run application (the documentation is also good, but you won't really need it).

Caveat: Your only option is to do a full copy of your disk volume, which means you really need an extra disk drive of some kind (I used an external one) with at least the same amount of free space as the total capacity of your physical disk with all its partitions. It is fast however - a couple of hours was all it took to clone my 160 Gb drive - fully acceptable.

I went with all recommended/standard options and chose a VMware Workstation or other VMware virtual machine as the destination type, since I wanted VMware Player to handle the computer from inside my new Windows 8 after the installation.

Problem: The first conversion failed at around 96% with an error message stating that it could not update drive letters. However, the virtual disk and the .vmx file was already there, so I went ahead and tried to boot it from VMWare Player, making sure the network interfaces on the toolbar were all turned off to avoid the physical computer and the virtual one to find each other. Of course, the VM would not boot, but went into the bluescreen of death (BSOD) after the initial progress bars.

Cause/Solution: One of the recommended settings was to use SCSI as the virtual disk controller. On a second conversion attempt, I only changed this to IDE (corresponding to the physical controller in my computer). Another couple of hours later, my VM was ready and booted fine.

Wednesday, September 11, 2013

TFS 2012 authenticates trusted domain users, but not groups

I am configuring my first Team Foundation Server (TFS) 2012 in a domain we can call TFSdomain, that has a one-way trust to another domain where most users will access TFS from, let's call it the UserDomain. I tried to add UserDomain\Domain Admins to the Team Foundation Administrators group to let one of the group's users, UserDomain\Administrator have access to the TFS Web Administration. It did not allow access.

The UserDomain\Domain Admins is also a member of the local BUILTIN\Administrators which is a member of the Team Foundation Administrators group. This gives access to TFSdomain\Administrator, but not to UserDomain\Administrator.

I then added UserDomain\Administrator directly to the Team Foundation Administrators and tried again. Now I was allowed access as expected.

I then noticed the icon of the UserDomain\Administrator entry in the Team Foundation Administrators group. It shows the icon for a single user - not for a group. It is also not possible to see group members from the TFS Administration Console.

Have I discovered a bug in TFS 2012, or is there some other reason for this behavior?

Saturday, May 25, 2013

Language neutral Pin shortcut to Start Menu using C#

Problem: I needed a program that would automatically pin an existing shortcut on the desktop to the start menu, regardless what localization the Windows user was using. I was using Windows Server 2008 R2 with a couple of alternate languages to English installed for testing. The program was written in C#. I hit the wall a copule of times while trying to make c# code from an earlier implementation written in VB.NET - this is a summary of what I got to work in the end:
Type shellAppType = Type.GetTypeFromProgID("Shell.Application");
Object oShell = Activator.CreateInstance(shellAppType);
Shell32.Folder oFolder = (Shell32.Folder)shellAppType.InvokeMember("NameSpace", System.Reflection.BindingFlags.InvokeMethod, null, oShell, new object[] { 0 }); //25 = common desktop, 0 is local desktop

if (System.IO.File.Exists(ShortcutTarget) & (oFolder != null))
   Shell32.FolderItem oFolderItem = oFolder.ParseName("somefile.lnk");
   Shell32.ShellLinkObject oShellLink = (Shell32.ShellLinkObject)oFolderItem.GetLink;
   if (oShellLink != null)
      // Find localized shell32 verb used to pin shortcut to the start menu (so that it works in any language)
      StringBuilder szPinToStartLocalized = new StringBuilder(MAX_PATH);
      IntPtr hShell32 = LoadLibrary("SHELL32");
      LoadString(hShell32, 5381, szPinToStartLocalized, MAX_PATH); // 5381 is the DLL index for "Pin to start menu", ref.
      string localizedVerb = szPinToStartLocalized.ToString();

      foreach (Shell32.FolderItemVerb verb in oFolderItem.Verbs())
         if (verb.Name == localizedVerb)

You need to reference Shell32 - i.e. Microsoft Shell Controls and Automation on the COM tab of your "Add reference" dialog in VS2010. Also make sure you copy the shell32.interop.dll along with your application when you move the application out of your bin folder.

The following problems were encountered and solved on the way:

BadImageFormatException when entering the method containing this code. The code worked well on a Windows Vista computer, but crashed when running on Server 2008 R2. I assume this happened because of the fact that Server 2008 R2 is a 64 bit OS, and this did not work well with using the unmanaged Shell32.
Solution: Change the target CPU of your application to x86. If you use VS2010 Express, this tip on StackOverflow may be helpful to you - Make sure to read all the answers if you are stuck.

InvokeVerb did not work. Before ending up using the line verb.DoIt(), I tried using oFolderItem.InvokeVerb(verb.Name), which used to work in an earlier VB.NET implementation of the same code. I have no explanation to why this did not work, but it did not. A conspiracy theory is that Nike paid them off to just do it...

By the way, this earlier post mentions a problem I encountered trying to do the same in VB.NET some time ago. It probably applies here too, which is why the top three lines of the code looks like they do.

Saturday, February 23, 2013

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
     RegExPattern="Something" Replacement="SomethingElse"
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:
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...