By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,426 Members | 2,928 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,426 IT Pros & Developers. It's quick & easy.

C++ debug/release builds and project references

P: n/a
I am having trouble getting debug and release builds to work properly
with project references using C++ .NET and Visual Studio 2003.

I created a test solution, with a basic Windows form C++ project.
I then add a class library, and add a reference to this project in the
first project.

When I do a release build, I see the following in the output from the
DLL compile:
/OUT:"C:\Documents and Settings\Andrew\My Documents\Visual Studio
Projects\DependencyTest\Release\test.dll"

OK so far.

When the windows form app compiles, however, I see:
/FU "c:\Documents and Settings\Andrew\My Documents\Visual Studio
Projects\DependencyTest\Debug\test.dll"

Where does this "Debug" come from? Everywhere else in the output says
"Release".

Can anyone tell me what I am doing wrong? How can I use a debug
version of a DLL for a debug build, and a release version for the
release build?
--
Andrew Rowley
Feb 1 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
I am having trouble getting debug and release builds to work properly
with project references using C++ .NET and Visual Studio 2003.

I created a test solution, with a basic Windows form C++ project.
I then add a class library, and add a reference to this project in the
first project.

When I do a release build, I see the following in the output from the
DLL compile:
/OUT:"C:\Documents and Settings\Andrew\My Documents\Visual Studio
Projects\DependencyTest\Release\test.dll"

OK so far.

When the windows form app compiles, however, I see:
/FU "c:\Documents and Settings\Andrew\My Documents\Visual Studio
Projects\DependencyTest\Debug\test.dll"

Where does this "Debug" come from? Everywhere else in the output says
"Release".

Can anyone tell me what I am doing wrong? How can I use a debug
version of a DLL for a debug build, and a release version for the
release build?
Hi,

How did you add the reference?
Did you select the DLL by browsing to it, or did your use the 'projects' tab
in the references dialog?

Also, if you open build->configuration manager
you can see how the debug / release builds are configured.
It could be possible that your solution release config is set to use the
release project setting for one project and the debug setting for another.

--
Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

Feb 1 '07 #2

P: n/a
je***@online.microsoft.com ("Jeffrey Tan[MSFT]") wrote:
>I have following questions to your problem:
1. Is your class library in configuration "Release"?
2. How do you add reference in the Winform project? Do you add the class
library dll in "Projects" tabpage(this is what I used in the test projects)
or browse to the ManagedClassLib.dll directly and add it as reference? I
suspect if you add the ManagedClassLib.dll in the debug folder.

I have also attached my sample test project in this reply. You may download
it through Outlook Express (not IE). You may give it a rebuilding on your
side and see if the "BuildLog.htm" still has this problem. Thanks.
Hi Jeffrey,

Thanks for the quick reply.

I'm not sure I understand your first question - the class library is
in configuration "release" when I have set the solution to release.

I added the reference in the projects tab page.

I downloaded your sample onto my machine and built it. However, before
building anything I changed the configuration to "Debug", since it
opened set to "Release". When I built the debug build, it failed when
it tried to reference the release dll. Output is below.

When I closed and reopened the solution, it built debug correctly -
which was what it was set to when it opened. If I then switch to
release, it builds, but refers to the debug dll.

Maybe I have something set strangely? You mentioned Ctrl+Shift+B to
build - I do F7 or select Build->Rebuild Solution - Ctrl+Shift+B
doesn't do anything for me.

Output from first build, with configuration set to debug:

Creating temporary file
"c:\tmp\ManagedWinform\ManagedClassLib\Debug\RSP00 0001.rsp" with
contents
[
/Od /AI "C:\tmp\ManagedWinform\ManagedWinform\Debug" /D "WIN32" /D
"_DEBUG" /D "_WINDLL" /D "_MBCS" /FD /EHsc /MTd /GS /Yu"stdafx.h"
/Fp"Debug/ManagedClassLib.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c
/Zi /clr /TP /FU
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\msco rlib.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Data.dll" /Zl
..\ManagedClassLib.cpp
..\AssemblyInfo.cpp
]
Creating command line "cl.exe
@c:\tmp\ManagedWinform\ManagedClassLib\Debug\RSP00 0001.rsp /nologo"
Creating temporary file
"c:\tmp\ManagedWinform\ManagedClassLib\Debug\RSP00 0002.rsp" with
contents
[
/Od /AI "C:\tmp\ManagedWinform\ManagedWinform\Debug" /D "WIN32" /D
"_DEBUG" /D "_WINDLL" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h"
/Fp"Debug/ManagedClassLib.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c
/Zi /clr /TP /FU
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\msco rlib.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Data.dll" /Zl
..\Stdafx.cpp
]
Creating command line "cl.exe
@c:\tmp\ManagedWinform\ManagedClassLib\Debug\RSP00 0002.rsp /nologo"
Creating command line "rc.exe /fo"Debug/app.res" .\app.rc"
Creating temporary file
"c:\tmp\ManagedWinform\ManagedClassLib\Debug\RSP00 0003.rsp" with
contents
[
/OUT:"C:\tmp\ManagedWinform\ManagedWinform\Debug\Ma nagedClassLib.dll"
/INCREMENTAL /NOLOGO /DLL /DEBUG /ASSEMBLYDEBUG
/PDB:"C:\tmp\ManagedWinform\ManagedWinform\Debug/ManagedClassLib.pdb"
/FIXED:No /noentry nochkclr.obj mscoree.lib kernel32.lib user32.lib
gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib "\Program
Files\Microsoft Visual Studio .NET 2003\Sdk\v1.1\Lib\mscoree.lib"
..\debug\AssemblyInfo.obj
..\debug\ManagedClassLib.obj
..\debug\Stdafx.obj
..\debug\app.res
]
Creating command line "link.exe
@c:\tmp\ManagedWinform\ManagedClassLib\Debug\RSP00 0003.rsp"

Output Window
Compiling...
Stdafx.cpp
Compiling...
ManagedClassLib.cpp
AssemblyInfo.cpp
Generating Code...
Compiling resources...
Linking...
nochkclr.obj : warning LNK4099: PDB 'libc.pdb' was not found with
'c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\lib\nochkclr.obj' or at
'C:\tmp\ManagedWinform\ManagedWinform\Debug\libc.p db'; linking object
as if no debug info

Results
Build log was saved at
"file://c:\tmp\ManagedWinform\ManagedClassLib\Debug\BuildL og.htm"
ManagedClassLib - 0 error(s), 1 warning(s)
------- Build started: Project: ManagedWinform, Configuration:
Debug|Win32 -------

Command Lines
Creating temporary file
"c:\tmp\ManagedWinform\ManagedWinform\Debug\RSP000 004.rsp" with
contents
[
/Od /AI "C:\tmp\ManagedWinform\ManagedWinform\Debug" /D "WIN32" /D
"_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yu"stdafx.h"
/Fp"Debug/ManagedWinform.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c
/Zi /clr /TP /FU
"c:\tmp\managedwinform\managedwinform\release\Mana gedClassLib.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\msco rlib.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Data.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Drawing.dll"
/FU
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Windows.Forms.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.XML.dll"
..\Form1.cpp
..\AssemblyInfo.cpp
]
Creating command line "cl.exe
@c:\tmp\ManagedWinform\ManagedWinform\Debug\RSP000 004.rsp /nologo"
Creating temporary file
"c:\tmp\ManagedWinform\ManagedWinform\Debug\RSP000 005.rsp" with
contents
[
/Od /AI "C:\tmp\ManagedWinform\ManagedWinform\Debug" /D "WIN32" /D
"_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h"
/Fp"Debug/ManagedWinform.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c
/Zi /clr /TP /FU
"c:\tmp\managedwinform\managedwinform\release\Mana gedClassLib.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\msco rlib.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Data.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Drawing.dll"
/FU
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Windows.Forms.dll"
/FU "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.XML.dll"
..\stdafx.cpp
]
Creating command line "cl.exe
@c:\tmp\ManagedWinform\ManagedWinform\Debug\RSP000 005.rsp /nologo"

Output Window
Compiling...
stdafx.cpp
stdafx.cpp(0) : fatal error C1192: #using failed on
'c:\tmp\managedwinform\managedwinform\release\Mana gedClassLib.dll'

Results
Build log was saved at
"file://c:\tmp\ManagedWinform\ManagedWinform\Debug\BuildLo g.htm"
ManagedWinform - 1 error(s), 0 warning(s)

regards

Andrew Rowley
--
Andrew Rowley
Feb 1 '07 #3

P: n/a
Bruno van Dooren [MVP VC++] <br**********************@hotmail.com>
wrote:
>How did you add the reference?
Did you select the DLL by browsing to it, or did your use the 'projects' tab
in the references dialog?
I used the projects tab in the references dialog.
>Also, if you open build->configuration manager
you can see how the debug / release builds are configured.
It could be possible that your solution release config is set to use the
release project setting for one project and the debug setting for another.
The release configuration is set to release for both projects, and the
debug configuration is set to debug for both projects.

See my reply to Jeffery - it might be happening only when I change
from one to the other, and seems to be a problem in either direction.

I suspect it has been happening to me for a long time, but went
unnoticed because there was always a debug and release dll there. I
think it only started causing me problems when I used strong names,
and ran into problems with mismatched version numbers.

Regards

Andrew Rowley
--
Andrew Rowley
Feb 1 '07 #4

P: n/a
Hi Andrew,

Thanks for your feedback.

Oh, yes, after following your steps, I can reproduce this problem
sometimes. Further research shows that this is a known issue of VS.net2003
project references, which has been fixed in VS2005(Whidbey).

In the bug record, the preferred work around is to use the /FU switch
directly through the project settings rather than using project references.

Personally, I find the following steps work for me:
1. after switching the config to "Release", click the "ManagedClassLib"
under the "References" node in "Solution Explorer". Check in the
"Properties" window that the "Full Path" points to the "release" dll.
2. First, right click the "ManagedClassLib" project and select "Rebuild"
menu item.
3. Then, right click the "ManagedWinform" project and select "Rebuild" menu
item.

Normally, these steps work well for me. You may give it a try.

Finally, I recommend you upgrade to the VS2005 IDE, which has fixed a lot
of bugs of VS.net2003. Also, VS2005 keeps a good backward compatibility
with VS.net2003 projects.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Feb 2 '07 #5

P: n/a
Thanks for the information. At least I now know what's going on, and
won't spend so much time chasing around in circles :-)

je***@online.microsoft.com ("Jeffrey Tan[MSFT]") wrote:
>In the bug record, the preferred work around is to use the /FU switch
directly through the project settings rather than using project references.
This worked well for the class library, unfortunately I also have a
user control with the same issue, and removing the project reference
stops the form designed from working. I guess I can build it
separately and just reference the release build, but it makes
debugging more tedious.
>Personally, I find the following steps work for me:
1. after switching the config to "Release", click the "ManagedClassLib"
under the "References" node in "Solution Explorer". Check in the
"Properties" window that the "Full Path" points to the "release" dll.
2. First, right click the "ManagedClassLib" project and select "Rebuild"
menu item.
3. Then, right click the "ManagedWinform" project and select "Rebuild" menu
item.

Normally, these steps work well for me. You may give it a try.
What I'm looking for is a solution I can set and forget, so this is
not ideal.
>Finally, I recommend you upgrade to the VS2005 IDE, which has fixed a lot
of bugs of VS.net2003. Also, VS2005 keeps a good backward compatibility
with VS.net2003 projects.
I am switching to VS2005 for a new project, but I need to target .NET
1.1 with the current project. My understanding is that using VS2005 I
can't target .NET 1.1 with C++ - is that correct?
>Hope this helps.
Very much, thanks.
--
Andrew Rowley
Feb 2 '07 #6

P: n/a
Hi Andrew,

Thanks for your feedback!

Yes, I see your concern. My suggestion is using VS.net2003 designer without
considering this issue, and after finishing the coding to the stage of
final building, you may use the /FU switch directly to target the correct
project configuration.

Yes, VS2005 can not build application with .Net Framework1.1. The only
solution to tell VS2005 to use .Net Framework1.1 is using MSBee. Please
refer my original thread below(take care of the URL line-break):
http://groups.google.com/group/micro...es.csharp/brow
se_frm/thread/a95a7b5d5ca4ecea/78224b3d8d29fc21?lnk=st&q=target+%22Jeffrey+T
an%22+VS2005+msbuild&rnum=1#78224b3d8d29fc21

Normally, .Net2.0 keeps a maximize backward compatibility with .Net1.1, so
in most situation you will not have no problem compiling .Net1.1 projects
with VS2005. The link below contains more details:
http://groups.google.com/group/micro...es.csharp/msg/
01b57f2f6f64bc48

If you still need any help or have any concern, please feel free to tell
me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Feb 5 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.