using #pragma comment(lib, "../../xxx.lib")
using Visual studio project option
What is the advantage and disadvantage between two method?
I'm finding way which is better convenient to manage for many projects.
And what method does Microsoft recommend?
The advantage of #pragma comment is that the user of your library cannot forget to add the setting. Or add the wrong one, it is not uncommon to get lost at the difference between the debug and release build and the /MD vs /MT build. One disadvantage is that troubleshooting linker problems can be difficult in some cases.
There's a third way that's hard to beat for convenience in a solution. Right-click the project that requires the library and click Project Dependencies. Tick the library project. This ensures that the library project is always built before the project and the .lib is automatically added.
Related
I have a solution which has two projects. One is a static link library project, and another is a console project for demo. Now I want to create a MFC project to replace the console project, what should I do to configure the MFC project.
the MFC project need to use some classes in the .lib project.
I have set MFC project as start project and depend on the .lib project.
My platform is win7 + vs2015.
Actually, the solution is EasyPR, you can get it here EasyPR.
Thanks for any help.
Setting the dependency to the static library is one step.
To compile the code you may need headers for the compiler. So the MFC projects may need settings for the compiler to define additional include paths.
You still need to configure the linker to use and find the library. To reference the library you may use a pragma comment lib. In the linker settings you may add an additional path for the libraries.
Or you may simply drag the lib into the solution explorer. The build mechanism will know how to treat a lib and will include it into the build process. The later will only work if you have 1 lib for release and debug.
If you have different libs for release and debug a advise you to use different names. You may adjust the project settings of the MFC program for debug and release differently.
I work on a large system (10+ EXEs and 50+ DLLs). The entirety of this system was written in C++ up until around 2005, when we began migrating components to the .NET framework.
It would help our migration efforts tremendously if I could switch individual DLL projects to C++/CLI and provide both a legacy unmanaged API and a new managed API into the same DLL.
This approach worked when we first started, but then broke soon after. Visual Studio does not appear to support two C++/CLI projects linking to each other via the unmanaged API.
Is there any way to get this to work beyond the brute-force approach of adding export libraries from one project as content to another? That's what project dependencies are supposed to handle already.
Perhaps #pragma comment in the native header files would be useful. For that to work you need each project configured to write its generated import library into a common area that can be added to the library search path, but it saves you from having to manually add lib files as linker inputs, or as project content items. Also, it makes keeping release and debug library versions separate more easily, since you can just have a different search path for each configuration, instead of having to add each individual library twice to every single consuming project.
I have a solution in Visual Studio 2013 (c# code) that has a reference to a third-party assembly that I added with NuGet (ICSharpCode.SharpZipLib). When I run the "Code Analysis" on the solution I get lots of warnings coming from the third-party assembly. How do I tell VS that I only want code analysis advice from my code?
I'm pretty sure the errors are coming from the library itself and not my usage of it. There are a total of 32 issues e.g.
CA2237: Mark ISerializable types with SerializableAttribute.
I am using ILMerge to bundle into a single executable do you think that has confused the code analysis?
There is no way to tell FxCop to ignore namespaces or types in your code if it lives in the same binaries. When using ILMerge, the SharpZipLib essentially becomes part of your code, as it's merged into your assembly.
To get proper results, run FxCop on the assembly that's generated before the merge.
Other solutions will mention to put a [GeneratedCode] attribute on classes you want excluded, but IlMerge has no option to to that while merging, so that won't help you out.
In Visual Studio 2015 Code Analysis works on the source code using the new Roslyn Engine, which will solve the issue probably, as it does the analysis even before compilation and as such will not be impacted by your use of IlMerge.
I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.
When you unload a project in Visual Studio, any referencing projects get warning triangles on their reference to the unloaded project. I've written myself a macro to do clever stuff (detect add/remove of project and transform any references from-to file/project dependency), but I can't believe that I'm not missing something much simpler. How can the unload function be any use if I have to go around manually changing references (and it breaks the 'personal solutions/shared projects' team development paradigm).
(This question is related to answers to this question about structuring large solutions in Visual Studio - some answers mentioned having solutions with lots of projects, but 'unloading' unused projects to improve performance.)
For my projects, I create an assemblies folder which the projects automatically copy into from a set location to which other projects copy builds.
Post-build for referenced assembly's project:
if not exist "C:\builds\Project1" md "C:\builds\Project1\"
copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
Pre-build for referencing projects:
if exist "c:\builds\Project1\" copy "c:\builds\Project1*.*" "$(ProjectDir)assemblies"
The project file points to its assemblies subfolder for references so even if the source projects are unloaded from the solution, the last-built assemblies will be used without the performance problems of having the whole project in memory while developing.
What are the advantages of having projects in the same solution if you use file references?
If your app.exe uses utils.dll and you change the code for utils.dll, then if it's in the same solution VS will notice the dependency and recompile both. If it's not in the solution you'll have to jump out, recompile utils.dll seperately, then jump back in and recompile app.exe.
This becomes either more or less important depending on how many other dll's your exe is referencing, and how often they change (in team environments shared dll's change often in my experience).
There is also the side effect that if you have 100 projects in VS it will take a long time to process them all just to figure out if they need recompiling or not.
Unloading projects is meant to be a temporary action so you can edit the actual project file as XML (text). If you want to completely remove a project from your solution, you should use the "Remove" menu option, which will take care of removing any references to that project.
One advantage to using project references is that it allows you to easily debug through the code. It also automatically ensures that you are using the correct configuration build (ie, if you are building in "Debug" mode it will use the Debug version of the assembly). That being said, you loose some determinisim about which version/build of the dependent project you will pick up - project references mean you always use the latest.
Yes, for Visual Studio to determine build dependencies it must be able to see and build all of the projects which would mean project references.
I've just had a eureka moment reading through MSDN doc on structuring solutions and projects.
What I hadn't noticed is that in a multi-project solution, the context menu in the Solution Explorer proposes a Project Dependencies popup. Here you can define the project dependencies manually, if you haven't defined them by project references between projects.
See here (MSDN link, so will self destruct after a few weeks)