views:

1126

answers:

4

I'm migrating a solution from visual studio 2005 to visual studio 2008. When I build the solution in 2005, I don't have any issues. However, after I use devenv.exe /Upgrade and then use msbuild on the solution, I get the following warnings:

CSC : warning CS1668: Invalid search path '\vc98\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified.' CSC : warning CS1668: Invalid search path '\vc98\mfc\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified. ' CSC : warning CS1668: Invalid search path 'c:\program files\microsoft visual studio 9.0\vc\platformsdk\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified.'

I have checked http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/3f875480-fee2-4bc3-b829-95e220b22a01 and it doesn't offer me any help because my LIB and INCLUDE environment variables are not set either in the user vars or the system vars. I've looked at Studio's Tools > Options > Projects and Solutions> VC++ Directories and there's nothing that references anything old:

Library Files: $(VCInstallDir)lib $(VCInstallDir)atlmfc\lib $(VCInstallDir)atlmfc\lib\i386 $(WindowsSdkDir)\lib $(FrameworkSDKDir)lib $(VSInstallDir) $(VSInstallDir)lib

Include files:

$(VCInstallDir)include $(VCInstallDir)atlmfc\include $(WindowsSdkDir)include $(FrameworkSDKDir)include

I used diagnostic output so that I could see exactly what the LIB variable includes when being called:

lib = c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;\vc98\lib;\vc98\mfc\lib;c:\program files\microsoft visual studio 9.0\vc\platformsdk\lib;c:\program files\microsoft visual studio 9.0\vc\lib;c:\program files\microsoft visual studio 9.0\vc\atlmfc\lib; LIBPATH = c:\Windows\Microsoft.NET\Framework\v3.5;c:\Windows\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB

So if that vc98 is NOT in my env vars, or my studio settings and vc98 isn't even installed (nor the redist), where is that path coming from? What process sets up the LIB env var like that?

A: 

Seems like you have covered most things here, so the only thing I can think of is inherited property sheets.

They are specified in the vcproj XML (or you can check the Property Manager in the IDE):

<VisualStudioProject>
    <Configurations>
        <Configuration InheritedPropertySheets="stuff.vsprops">...

If you do have some inherited property sheets, go have a look in the file and see if you have any vc98 lib paths set explicitly?

Cannonade
Nope. I don't have a single InheritedPropertySheets attribute in any VCProj file that's being migrated.
Mike Caron
Sorry to hear that Mike. That was my best guess.
Cannonade
No apologies necessary. I'm hoping that some Microsofty will know what's going on.
Mike Caron
Got my fingers crossed. I'll be interested to know what the problem was.
Cannonade
A: 

I am wondering if this could be due to the change in using the compiler switches /MT and /MTd from /ML and /MLd which occured for VS2005 relating to C runtime libraries?

Refer to here and see if it helps: http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

ChrisBD
haven't had a chance to check this yet. Hope I can get to it today or tomorrow.
Mike Caron
+1  A: 

Found on MSDN:

Yes this is a known issue that occurs to some people. Look carefully in your LIB path. Right after ATLMFC, V, SDK -> \vc98\lib. Delete this entry (and the one that follows). If the LIB is a user variable then you'll need to restart VS or perhaps log off and back on. If it is a system variable then you'll have to reboot. Your error should then go away.

compie
A: 

I'm having a very similar issue with C# projects in VS.NET2010. It appears only to affect those projects which import C++/CLI projects. The projects are still set to compile using the v9.0 toolset(C++, C++/CLI) and .NET 3.5 (C++/CLI, C#). Have you had any luck finding the source of the problem?

I worked around it by adding warning 1668 to the ignored warnings list in the properties of the affected projects. That's not ideal, but better than spam in my warnings list.

Eamon Nerbonne