dll project for which i want to create unit tests.
In order to run unit tests i need my test project to compile all dependencies and i don't want to add my cpp files to test project.
The solution is to add lib in references but i have no clue how should i compile my project as both dll and as lib. Is this even possible ? I suggest that could be easy with naked cmake/make.
What i could do is create another project with same files and build it as a .lib. I think this solution is very primitive and it will require me to add .cpp files to projects twice if i ever want to add something new. I would prefer a solution in which i could have only one project in solution and have it build .dll (a main component) and a .lib for UT project reference.
I know i could also make UT load my .dll and have that kind of dynamic linkage, but that would make it harder due the need of creation of dll wrapper to access those functions.
I also considered using batch build and have custom build configuration. But this will require me to batch build every time i want to run UTs. I'd rather have it chose automaticaly. Maybe if i set UT project to be build under custom configuration the dependency will also be build with custom config?
Does Visual Studio 2015 bring any simple solution to this problem?
Related
Actually, question was set in the Theme of the message. But yet again,
i have Solution with 3 projects, two of whitch are Static libraries and one is Application. How my Application project could know from where to pull these .libs.
Yeh, i can do it from Linker->Input->Additional libraries, but i think there are must be other way if projects are in one solution.
There is another way, works on VS2010 and up. Right-click your EXE project, Properties, Common Properties, Framework and References. Click the Add New Reference button and select your project that generates the .lib. Repeat as necessary.
This does two things, it takes care of the Additional Dependencies linker setting, automatically adding the output of the library project. And it ensures that projects are built in the right order, normally something you'd have to with the Project Dependencies command. In your given example, with enough machine horsepower, the library projects will build concurrently. And the main project won't start building until they are both done.
I'm quite new to QtCreator, so perhaps I left my heart in eclipse-ville, but I can't for the life of me understand how I should be setting up a project hierarchy in QtCreator. I understand there is an option to create a kind of root project and then from there add sub-projects to it, which makes sense but it leaves me wondering whether or not this is necessary at the time of creating the project, e.g. can I just create a library in one project and reference it later by another project?
I've tried setting up a blanket type of project by creating a new subdirs project and then adding the main program as a subproject, but then how should I add my library project?
Ideally, I'd like to create one project as the main application and reference another project as a library. Help?
The documentation of Qt Creator contains two sections that may help you find the answers to your questions:
Adding Subprojects to Projects
Adding Libraries to Projects
EDIT:
You can find a really simple sample project here: QtSymbianDllExample. "It is intended to demonstrate how to create and use a DLL with Qt on the Symbian platform". It is a sample for Symbian development but that is irrelevant now, I do not have a Symbian phone. What is important is that it contains a root project (QtSymbianDllExample\qtssymbiandllexample.pro) and two subprojects (QtSymbianDllExample\qtenginedll\qtenginedll.pro, QtSymbianDllExample\testui_simpledllengine\testui_simpledllengine.pro) which you can examine and compare to you projects. I have checked that I can build the root project by doing the following steps:
Download and install the Windows Offline Installer from http://www.qt.io/download/
Download and extract QtSymbianDllExample.zip
Run Qt Creator
File / Open File or Project... Select qtssymbiandllexample.pro
Build / Run qmake
Build / Build project "qtsymbiandllexample"
I have a solution wich consists of main application MainProject and several plugin projects Plugin1, Plugin2 etc. Each of them is build in a separate project within Visual Studio.
For building the soution, I want all files of the plugins to be copied into the main application's output directory. But I don't want MainProject.exe to contain explicit references to the plugin dlls (they are loaded dynamically). Therefore defining project references for MainProjectdoesn't work.
I could use a post-build-step copying the files "manually" (as described in C# - Copy dlls to the exe output directory when using dependency injection with no references?), but since there might be multiple files for each plugin and they also change from time to time this solution is rather tedious to maintain (especially since I do have different build configurations, each of them producing different files). Also I would like to easily select, which plugins should be copied for a certain build.
What would be the best way, possibly involving custom MSBuild configuration changes, to do this?
See this link: http://msdn.microsoft.com/en-us/library/bb629394%28v=vs.100%29.aspx
When invoking MSBuild on the main project, if you could pass something on the lines of:
msbuild /p:CustomBeforeMicrosoftCommonTargets=[your custom msbuild file];PluginList=PathToPlugin1.csproj,PathToPlugin2.csproj
In your custom msbuild file, a target such as GatherInfo will get you the paths to output files of each plugin project. See this question for a sample: https://stackoverflow.com/questions/23346782/how-to-identify-files-needed-to-build-a-wix-project
I have a unit test which depends on some code that uses MEF. When I run the test, MEF (I believe) MEF tries to load all dependent DLLs for all the DLLs in the unit test's executing directory.
The problem is that VS2010 for some reason isn't copying all the DLLs from the /bin/debug directory to the unit test's executing directory, and I don't know why. Here's an example:
Unit test is complaining is can't load assembly A, so I include project B which assembly A has as a dependency. In the /bin/debug folder for the unit test project, all the DLLs are in there, but when I look at the unit test's executing directory, assembly A isn't there.
I could start adding DLLs as refs to the unit test project one by one, but I feel like I should have to.
Thoughts?
thanks,
Mark
Maybe the DeploymentItem attribute can help, http://msdn.microsoft.com/en-us/library/ms182475.aspx:
For the parameter of the DeploymentItem attribute, specify the folder
or file that you want to deploy for this test. You can use either an
absolute path or a relative path. Relative paths are relative to the
RelativePathRoot setting found in the .testrunconfig file.
[TestMethod]
[DeploymentItem("MyTestProject\\testdatasource.mdb")]
public void TestMethod1()
{
// TODO: Add test logic here
}
You can add the project as a reference and it will sort it out.
Right click add ref project tab.
Dont ref the dll itself in teh bin\debug folder.
As test projects are simply extensions of the production code, it's not uncommon to share the same dependencies. In some cases, excluding a dependency may compile fine but will fail when the code under test tries to load a missing dependency at runtime (as you've discovered). If your tests however have to use a dependency in the test code, you'll find that you won't be able to compile without referencing that dependency.
Also keep in mind that when you execute a TestRun with MSTest, it's not the compilation process that copies the assemblies -- there's a post compilation step that copies the dependencies for the tests to a specialized "test run" folder, typically under TestResults. Visual Studio supports a feature called "Test Deployment" that can copy additional test data, etc to the test run.
The other element at play here may be the dynamic composition nature of MEF. One of the key benefits of MEF is that it follows a plugin model that dynamically loads assemblies into your application at runtime: simply drop in new assemblies and MEF will pick them up. As such, it's common that the design of the main application will not have direct references to these dynamically loaded assemblies. If you're using MEF in your tests to dynamically load tests, these tests must be copied (using Test Deployment) or referenced as part of the test project.
I'm using Castle Windsor to do some dependency injection, specifically I've abstracted the DAL layer to interfaces that are now being loaded by DI.
Once the project is developed & deployed all the .bin files will be in the same location, but for while I'm developing in Visual Studio, the only ways I can see of getting the dependency injected project's .bin file into the startup project's bin folder is to either have a post-build event that copies it in, or to put in a manual reference to the DAL project to pull the file in.
I'm not totally thrilled with either solution, so I was wondering if there was a 'standard' way of solving this problem?
Could you set the build output path of the concrete DAL project to be the bin folder of the dependent project?
Mike: Didn't think of that, that could work, have to remember to turn off copy-local for any libraries / projects that are common between them