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

Where's my dll after I build?

P: n/a
I created a managed C++ dll project. I wrote the code and compiled it and
everything builds fine. The problem is no prj.dll is generated in the
output directories. It does generate a prj.dll.intermediate.manifest that's
1k and all the obj files. How do I get a dll? What I ended up doing was
creating a quick C# project and, a reference to the C++ project and setting
copy local to true. Then I went to the C# output folder and there it was.

My question is how do I generate the dll without having to build another
project and create a reference to it? There must be a way.

Thanks in advance,
jim
Oct 16 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
I created a managed C++ dll project. I wrote the code and compiled it and
everything builds fine. The problem is no prj.dll is generated in the
output directories. It does generate a prj.dll.intermediate.manifest that's
1k and all the obj files. How do I get a dll? What I ended up doing was
creating a quick C# project and, a reference to the C++ project and setting
copy local to true. Then I went to the C# output folder and there it was.

My question is how do I generate the dll without having to build another
project and create a reference to it? There must be a way.
Your DLL is built.
It is just not in the project output folder.
Check the output folder on solution level. That will contain the main ouput
of your DLL project. this is normal.

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

Oct 16 '06 #2

P: n/a
"Bruno van Dooren [MVP VC++]" <br**********************@hotmail.comwrote
in message news:9F**********************************@microsof t.com...
>I created a managed C++ dll project. I wrote the code and compiled it
and
everything builds fine. The problem is no prj.dll is generated in the
output directories. It does generate a prj.dll.intermediate.manifest
that's
1k and all the obj files. How do I get a dll? What I ended up doing was
creating a quick C# project and, a reference to the C++ project and
setting
copy local to true. Then I went to the C# output folder and there it
was.

My question is how do I generate the dll without having to build another
project and create a reference to it? There must be a way.

Your DLL is built.
It is just not in the project output folder.
Check the output folder on solution level. That will contain the main
ouput
of your DLL project. this is normal.

--
Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"
Thanks,
I didn't know that solutions had output. You are right, it is there. Where
are the solution output folders set? I can't find them (VS 2005). Kind of
silly since none of the other project types work like that. Is that true
for all C++ projects now. I haven't done that much with windows C++ in VS
2005.

jim
Oct 16 '06 #3

P: n/a
>>My question is how do I generate the dll without having to build another
>>project and create a reference to it? There must be a way.

Your DLL is built.
It is just not in the project output folder.
Check the output folder on solution level. That will contain the main
ouput
of your DLL project. this is normal.

Thanks,
I didn't know that solutions had output. You are right, it is there.
Where are the solution output folders set? I can't find them (VS 2005).
Kind of silly since none of the other project types work like that. Is
that true for all C++ projects now. I haven't done that much with windows
C++ in VS 2005.
SolutionDir is a configuration value. it is simply the path of your solution
file.
If you look at your project properties under general, you'll see that the
output dir is set to $(SolutionDir)$(ConfigurationName).
This means that the output goes to the solution output dirs.

The reason for this is that your different projects then all put their
output in the same place.
This way, if you have an app that depends upon several other dll projects,
all dlls are where the app can find them.
Otherwise you'd have to create post-build steps to copy those dlls around.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Oct 16 '06 #4

P: n/a
"Bruno van Dooren [MVP VC++]" <br**********************@hotmail.comwrote
in message news:uJ**************@TK2MSFTNGP03.phx.gbl...
>>>My question is how do I generate the dll without having to build
another
project and create a reference to it? There must be a way.

Your DLL is built.
It is just not in the project output folder.
Check the output folder on solution level. That will contain the main
ouput
of your DLL project. this is normal.

Thanks,
I didn't know that solutions had output. You are right, it is there.
Where are the solution output folders set? I can't find them (VS 2005).
Kind of silly since none of the other project types work like that. Is
that true for all C++ projects now. I haven't done that much with
windows C++ in VS 2005.

SolutionDir is a configuration value. it is simply the path of your
solution file.
If you look at your project properties under general, you'll see that the
output dir is set to $(SolutionDir)$(ConfigurationName).
This means that the output goes to the solution output dirs.

The reason for this is that your different projects then all put their
output in the same place.
This way, if you have an app that depends upon several other dll projects,
all dlls are where the app can find them.
Otherwise you'd have to create post-build steps to copy those dlls around.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Thanks again. C# projects don't work like that. They work the way the old
C++ projects used to. They have a bin directory under PROJECT_DIR and a
debug and release under that. references from other projects get copied
into the main applications debug or release dir when copy local is set to
true. By default when you add a reference to a project copy local is set to
true. So far C++ projects are the only ones I have found that use the
solution's release or debug folders. Personally, I don't like it. I think
everything should operate the same, VB.NET, C#.NET, even ASP.NET all default
to output folders in their respective project folders. Projects can be part
of multiple solutions and the copy local option takes care of getting the
app access to the correct referenced dll.

I just noticed that the output directory in the C++ project actually says
SolutionDir\ConfigurationName. I changed it to ProjectDir to make it
consistent with the other projects in the solution. I don't mind it so much
now that I see the output dir can be changed. I missed this before because
the intermediate files were all in the prom\debug folders. Sorry for the
rant.

Thanks again,
jim
Oct 17 '06 #5

P: n/a
Hi Jim,
>Thanks again. C# projects don't work like that. They work the way
the old C++ projects used to. ...
So far C++ projects are the only ones I have found that use the
solution's release or debug folders. Personally, I don't like it.
I think everything should operate the same, VB.NET, C#.NET,
even ASP.NET all default to output folders in their respective
project folders.
I am afraid the VC++ project has its own directory layout, this setting is
by default since the VC product series. The bin directory is used in the
non-VC .NET language project types as you mentioned.

I suggest you can submit this feedback to our product feedback center, our
development team may communicate with you directly on the issue there:

http://connect.microsoft.com/site/si...spx?SiteID=210
Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Oct 17 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.