Hideki A. Ikeda (HidekiAI) [池田英紀] ["Tony" Ikeda] – BLog

I usually prefer not to BLog about work or things I’ve discovered (or learned) at work because I believe it to be intellectual properties of my company I work for. But this is a BLog about an incident in which I’ve lost close to 8 work-hours that I believe is not really an I.P. issue.

My hard-drive had crashed about (less than) a month ago, and to avoid lost time and in hopes to immediately get back to work, I had our I.T. personal just re-image the “developer configuration” of the PXE which had XP SP2 and Visual Studio 8 (SP1) pre-installed.

After a while, I’ve started to notice that I’d constantly get “Internal Compiler Error” (ICE) when compiling header files that has templates, as well as having major difficulties with projects that are either C++/CLI /clr (Managed C++) or C# based projects.

It was quite common that I’d have to juggle back and forth between compiling from IDE and then try to compile the .SLN (or sometimes, specific .VCProj or .CSProj) from command line either via MSBuild or Devenv.com (don’t use Devenv.exe, it will hang sometimes) and things would move on after several minutes (of wasted time) futzing around with it.

In certain cases, some of the projects would fail because it could not find the Assembly References of the dependant project, and I’d sometimes get the error about “#using MyAssemblyFile” failure because the “MyAssemblyFile.DLL” could not be found.

These “MyAssemblyFile.DLL” was (as it turns out) commonly of C# based assembly files most of the time, which some of our Managed C++ referenced.

When I look at the $(OutputDir) of where the C# project was supposed to generate the .DLL to, it is not there, but it is found in the obj/Debug folder.  That kind of threw me off because it told me that it is building and generating tartget ouput file, but it was just not generating to the correct folder.

If you have looked into .CSProj, the $(OutputDir) is always relative path.  Even if you enter it as an absolute path, Visual Studio will make it relative.  It is a good way to verify (by setting it as absolute) so you can prove to yourself that you’re not insane.

Then I remembered somewhere on MSDN forum that somebody was complaining that they can build projects as an Administrator login but not as themselves (as normal user login).

So I gambled and right-clicked on my C:\ folder from the desktop and give “Full Control” access to my domain-user account so that I have write-access to my entire drive.  That did not help…

After completely uninstalling Visual Studio and re-installing, I realized that my Visual Studio was registered under some generic name that does not exist, the PXE image, when built, was purposely installed with some bogus username (for this example, we’ll just call it “Dev User“) so that it can be imaged for any new employees or unlucky souls like myself who has had their harddrive crash.  I noticed this because I was ready to enter the Visual Studio license but when I got to that screen, it was greyed out because it had remembered the username (as “Dev User”) and the licence key.

After re-install, I’ve crossed my fingers and tried to rebuild our project, yet again, it did not generate the Assembly DLL’s to the targeted $(OuputDir) folder…

Enough suspense…  So as it turns out, it seems as though the security of user “Dev User” for any CLR based projects (such as C# and VB) needs ACL privileges based on the registered user to write to the $(OutputDir) folder.

So I launched RegEdt32.exeand searched-and-replaced all the values that had this “Dev User” with my domain name.  Closed Visual Studio, re-opened it (so that it would think the user is me now) and compiled.  This time, the Assembly .DLLs was generated to $(OutputDir) as expected.

I’ve had issues in the past like this, for example I was using Cygwin’s version of SVN rather than CollabNet’s SVN Command line Client, and Cygwin’s SVN would set the file privileges based on local user generated for Cygwin, and when I ran our Application via Visual Studio IDE, it would exit the game without any reason (access violations to the data checked out via Cygwin’s SVN was the problem).

In Linux, you’d catch these kind of issues quick, for example if you (not as a root) tried to write to /usr/lib or /usr/include, you’d know immediately!

I hope that if you are reading this, that you’ve only lost few minutes of your time and not hours like I did tracking this issue down.

Related posts

• XNA with VC8 (C++) Express Edition 2005 (0)
• Why MSVC programmers are spoiled (0)
• Visual Studio 2010 and C++’0x (0)
• Visual Studio .NET 2005 + I.C.E. (Internal Compiler Error) (0)
• Use your O/S to Multi-Process (0)