| Groups | Blog | Home |
visual studio .net general : VS.NET 2003 fails to build Managed C++ project from command line
having a VS.NET solution that contains a Managed C++ project that has a "Project reference" to another assembly (C# for example), will build successfully in the IDE, but not on the command line (i.e. devenv /build solution.sln). Any resolution exists on this issue? Richard
Cannot do file assembly references: we need to have project references so to
refer the proper assembly depending on the configuration being built (debug or release)... So, we do need a project reference, and how does this become a product limitation?? In my view, it's called a bug. Richard [quoted text, click to view] ""Gary Chang[MSFT]"" wrote:
> Hi Richard, > > >VS.NET 2003 fails to build Managed C++ project from command > >line. That is, having a VS.NET solution that contains a Managed > >C++ project that has a "Project reference" to another assembly > >(C# for example), will build successfully in the IDE, but not on the > >command line (i.e. devenv /build solution.sln). > > I have performed some tests on this issue, also got the same results as you > described. > > After some research and comparing the BuildLog.htm files of that managed > C++ project in different scenarios, I found the problem may be the build > command line could not process the "Project reference" dependency, the > tempory build script which generated by the invisible VS2003 IDE will not > link to the Project refernced assembly(the assembly in its obj\debug\ > directory): > ... > Creating command line "cl.exe @"e:\Gary\My Documents\Visual Studio > Projects\W4\gif2\Debug\RSP000001.rsp" /nologo" > Creating temporary file "e:\Gary\My Documents\Visual Studio > Projects\W4\gif2\Debug\RSP000002.rsp" with contents > [ > /Od /AI "E:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug" /D > "WIN32" /D "_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h" > /Fp"Debug/gif2.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Zi /clr /TP /FU > "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Drawing.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Windows.Forms.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.XML.dll" > ".\stdafx.cpp" > ] > > So the build process failed with some error as cound not find a namespace > definition which should be provided by the referenced assembly. > > On the other hand, if the managed C++ project referenced that .NET assembly > directly(the assembly(.dll) in its bin\debug\ directory), then the command > line build would work fine: > ... > Creating command line "cl.exe @"e:\Gary\My Documents\Visual Studio > Projects\W4\gif2\Debug\RSP000002.rsp" /nologo" > Creating temporary file "e:\Gary\My Documents\Visual Studio > Projects\W4\gif2\Debug\RSP000003.rsp" with contents > [ > /Od /AI "E:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug" /D > "WIN32" /D "_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h" > /Fp"Debug/gif2.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Zi /clr /TP /FU > "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Drawing.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Windows.Forms.dll" > /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.XML.dll" > /FU "E:\Gary\My Documents\Visual Studio Projects\W4\tst2\bin\Debug\tst2.dll" > ".\stdafx.cpp" > ] > > So this appears to be an product limitation to the VS2003 IDE, I suggest > you reference the .NET assembly to your managed C++ project directly, and > the referenced assembly should be the one in its project's output > directory(..\bin\debug\ or ..bin\release\ ) . > > > Thanks! > > Best regards, > > Gary Chang > Microsoft Community Support > -------------------- > Get Secure! ¡§C www.microsoft.com/security > Register to Access MSDN Managed Newsgroups! > http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp > &SD=msdn > > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Richard,
[quoted text, click to view] >VS.NET 2003 fails to build Managed C++ project from command >line. That is, having a VS.NET solution that contains a Managed >C++ project that has a "Project reference" to another assembly >(C# for example), will build successfully in the IDE, but not on the >command line (i.e. devenv /build solution.sln). I have performed some tests on this issue, also got the same results as you described. After some research and comparing the BuildLog.htm files of that managed C++ project in different scenarios, I found the problem may be the build command line could not process the "Project reference" dependency, the tempory build script which generated by the invisible VS2003 IDE will not link to the Project refernced assembly(the assembly in its obj\debug\ directory): ... Creating command line "cl.exe @"e:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug\RSP000001.rsp" /nologo" Creating temporary file "e:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug\RSP000002.rsp" with contents [ /Od /AI "E:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug" /D "WIN32" /D "_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h" /Fp"Debug/gif2.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Zi /clr /TP /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Drawing.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Windows.Forms.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.XML.dll" ".\stdafx.cpp" ] So the build process failed with some error as cound not find a namespace definition which should be provided by the referenced assembly. On the other hand, if the managed C++ project referenced that .NET assembly directly(the assembly(.dll) in its bin\debug\ directory), then the command line build would work fine: ... Creating command line "cl.exe @"e:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug\RSP000002.rsp" /nologo" Creating temporary file "e:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug\RSP000003.rsp" with contents [ /Od /AI "E:\Gary\My Documents\Visual Studio Projects\W4\gif2\Debug" /D "WIN32" /D "_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h" /Fp"Debug/gif2.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Zi /clr /TP /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Drawing.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Windows.Forms.dll" /FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.XML.dll" /FU "E:\Gary\My Documents\Visual Studio Projects\W4\tst2\bin\Debug\tst2.dll" ".\stdafx.cpp" ] So this appears to be an product limitation to the VS2003 IDE, I suggest you reference the .NET assembly to your managed C++ project directly, and the referenced assembly should be the one in its project's output directory(..\bin\debug\ or ..bin\release\ ) . Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
[quoted text, click to view]
>So, we do need a project reference, and how does this become > a product limitation?? In my view, it's called a bug. yes Richard, this issue would be an issue to the VS2003 IDE, I have also test this case with VS2005 August CTP version, the MC++ project with the project dependency reference could be built well with the command line under VS2005. We are regret it doesn't works in VS2003, and we understand the inconveniece which this problem brought to your development. But at the current stage, if you want a workaround/hotfix to VS2003, I suugest you contact our PSS support, this may need you submit a support incident in Microsoft PSS (Product Support Service). As a MSDN subscriber, you have two free support incidents. By the way, if the problem is confirmed by Microsoft PSS as a product issue, PSS won't charge money. Every MSDN subscriber has two free support incidents. You could use one of them to contact Microsoft PSS. So you don't need to pay money yet. Surely if the issue is a product issue, you still have two free support incidents. For your reference, I attached steps to contact Microsoft PSS here: You can contact Microsoft Product Support directly to discuss additional support options you may have available, by contacting us at 1-(800)936-5800 or by choosing one of the options listed at http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer prophone If there is anything unclear, please feel free to post here. We are glad to be of assistance. Thanks for your understanding! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
[quoted text, click to view]
Gary Chang[MSFT] wrote: >>So, we do need a project reference, and how does this become >>a product limitation?? In my view, it's called a bug. > > > yes Richard, this issue would be an issue to the VS2003 IDE This is not an /issue/, it is a *BUG* -- go ahead and say it, I know that you can... [quoted text, click to view] > We are regret it doesn't works in VS2003, and we understand the > inconveniece which this problem brought to your development. Inconvenience to his development??? It has caused a lot of wasted time, effort, and money to a *lot* of people/teams. [quoted text, click to view] > if you want a workaround/hotfix to VS2003, I suugest you > contact our PSS support, this may need you submit a support incident in > Microsoft PSS (Product Support Service). As a MSDN subscriber, you have two > free support incidents. Or, how about just posting a hotfix somewhere and let us download it without having to go through the stupid PSS gyrations. I think that you need to realize that our time isn't free, we have already spent a lot of time debugging your app for you. This may be news to MS product support, but we do *NOT* want to have to fool around w/ needless calls to problems with your product that we *PAID* for. [quoted text, click to view] > If there is anything unclear, please feel free to post here. We are glad to > be of assistance. You haven't been of assistance. There is no reasonable solution to the problem, it isn't even clear if PSS could do anything about it *after* we spent hours discussing the problem and how to duplicate. Is there even a 'hotfix' out there for this 'issue'? Try this on for 'assistance': A) hello -- yes, this is a known problem with VS 2003. Contact PSS and mention issue #<some_number> and they will be able to provide you with a hotfix free of charge. B) hello -- yes, this is a known problem with VS 2003. You can download a hotfix from ftp://ftp.microsoft/com/... This is an untested fix, please use at your own risk. Now, either one of those responses would be considered *ASSISTANCE*. [quoted text, click to view] > Thanks for your understanding! Gary -- we *DON'T* understand. This is a problem with your product, and
Hahahah!
Looks like you have hit the same problem... I have contacted support and here are the workarounds: Problem This solution that contains two projects will build correctly in the VS.NET IDE, but will fail to build from the command line. Action Confirmed with the CPRs that this is a known bug and suggested workarounds. Cause Known bug – fixed in Visual Studio 2005. Resolution/Workaround - use #using <full path ofr CSharpProject.dll> - use /FU CSharpProject.dll /AI <path to CSharpProject.dll> - File Reference rather than Project reference. [quoted text, click to view] "Peter Franks" wrote:
> Gary Chang[MSFT] wrote: > >>So, we do need a project reference, and how does this become > >>a product limitation?? In my view, it's called a bug. > > > > > > yes Richard, this issue would be an issue to the VS2003 IDE > > This is not an /issue/, it is a *BUG* -- go ahead and say it, I know > that you can... > > > We are regret it doesn't works in VS2003, and we understand the > > inconveniece which this problem brought to your development. > > Inconvenience to his development??? It has caused a lot of wasted time, > effort, and money to a *lot* of people/teams. > > > if you want a workaround/hotfix to VS2003, I suugest you > > contact our PSS support, this may need you submit a support incident in > > Microsoft PSS (Product Support Service). As a MSDN subscriber, you have two > > free support incidents. > > Or, how about just posting a hotfix somewhere and let us download it > without having to go through the stupid PSS gyrations. I think that you > need to realize that our time isn't free, we have already spent a lot of > time debugging your app for you. > > This may be news to MS product support, but we do *NOT* want to have to > fool around w/ needless calls to problems with your product that we > *PAID* for. > > > If there is anything unclear, please feel free to post here. We are glad to > > be of assistance. > > You haven't been of assistance. There is no reasonable solution to the > problem, it isn't even clear if PSS could do anything about it *after* > we spent hours discussing the problem and how to duplicate. Is there > even a 'hotfix' out there for this 'issue'? > > Try this on for 'assistance': > > A) hello -- yes, this is a known problem with VS 2003. Contact PSS and > mention issue #<some_number> and they will be able to provide you with a > hotfix free of charge. > > B) hello -- yes, this is a known problem with VS 2003. You can download > a hotfix from ftp://ftp.microsoft/com/... This is an untested fix, > please use at your own risk. > > Now, either one of those responses would be considered *ASSISTANCE*. > > > Thanks for your understanding! > > Gary -- we *DON'T* understand. This is a problem with your product, and > there is no solution.
Try :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxgrfcommandlineswitches.asp (likely the /projectconfig switch) -- <noogie.brown@gmail.com> a écrit dans le message de news:1130940340.479972.231430@f14g2000cwb.googlegroups.com... [quoted text, click to view] > <SNIP> > > Hi All, > > I've managed to come up with a half work around: > > I chose to use bash running under cygwin ( http://cygwin.com ) to write > out automated builds, because it's that bit more flexible that a batch > file. > > After doing a devenv /? , I found the /commands switch. > > So, I now do something like this: > > (note: devenv is a symlink to devenv.exe) > > echo "Spawning visual studio for $OFFENDINGPROJECT..." > devenv "MySolution.sln" /commands Build.RebuildSolution > devenvpid="$!" > sleep 30 # or sufficient time for your build to run > kill "$devenvpid" > > I'm not sure how you can force a particular configuartion, at the > moment I'm relying on it being saved in Release. And I'm having a > problem with the sou file missing dialog getting in the way, but apart > from that, I think I might be onto something (fingers crossed) > > Hope that's of some use to someone. > > Cheers > Alex >
<SNIP>
Hi All, I've managed to come up with a half work around: I chose to use bash running under cygwin ( http://cygwin.com ) to write out automated builds, because it's that bit more flexible that a batch file. After doing a devenv /? , I found the /commands switch. So, I now do something like this: (note: devenv is a symlink to devenv.exe) echo "Spawning visual studio for $OFFENDINGPROJECT..." devenv "MySolution.sln" /commands Build.RebuildSolution devenvpid="$!" sleep 30 # or sufficient time for your build to run kill "$devenvpid" I'm not sure how you can force a particular configuartion, at the moment I'm relying on it being saved in Release. And I'm having a problem with the sou file missing dialog getting in the way, but apart from that, I think I might be onto something (fingers crossed) Hope that's of some use to someone. Cheers Alex
[quoted text, click to view] Patrice wrote: > Try : > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxgrfcommandlineswitches.asp > > (likely the /projectconfig switch) > > -- > Got both problems fixed by caching a SUO file on our build machine and copying it into the directory of the solution before doing calling devenv. The SUO file contains the configuration to be in when starting up, so having that set to release is fine. So Im happy :-) Note to others who might be put off by cygwin - I guess you could just use a batch file, but you wouldn't be able to kill the IDE after. But at least it would build.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |