How to create and reuse packages based on Visual Studio
Conan has different helpers to manage Visual Studio and MSBuild based projects. This how-to illustrates how to put them together to create and consume packages that are purely based on Visual Studio. This how-to is using VS2015, but other versions can be used too.
Creating packages
Start cloning the existing example repository, containing a simple “Hello World” library, and application:
$ git clone https://github.com/memsharded/hello_vs
$ cd hello_vs
It contains a src
folder with the source code and a build
folder with a Visual Studio 2015 solution,
containing 2 projects: the HelloLib static library, and the Greet application. Open it:
$ build\HelloLib\HelloLib.sln
You should be able to select the Greet
subproject -> Set as Startup Project
.
Then build and run the app with Ctrl+F5. (Debug -> Start Without Debugging)
$ Hello World Debug!
# Switch IDE to Release mode, repeat
$ Hello World Release!
Because the hello.cpp
file contains an #ifdef _DEBUG
to switch between debug and release message.
In the repository, there is already a conanfile.py
recipe:
from conans import ConanFile, MSBuild
class HelloConan(ConanFile):
name = "Hello"
version = "0.1"
license = "MIT"
url = "https://github.com/memsharded/hello_vs"
settings = "os", "compiler", "build_type", "arch"
exports_sources = "src/*", "build/*"
def build(self):
msbuild = MSBuild(self)
msbuild.build("build/HelloLib/HelloLib.sln")
def package(self):
self.copy("*.h", dst="include", src="src")
self.copy("*.lib", dst="lib", keep_path=False)
def package_info(self):
self.cpp_info.libs = ["HelloLib"]
This recipe is using the MSBuild() build helper to build the sln
project.
If our recipe has requires
, the MSBUILD
helper will also take care of inject all the needed
information from the requirements, as include directories, library names, definitions, flags etc
to allow our project to locate the declared dependencies.
The recipe contains also a test_package
folder with a simple example consuming application.
In this example, the consuming application is using cmake to build, but it could also use Visual Studio too.
We have left the cmake one because it is the default generated with conan new, and also to show that packages
created from Visual Studio projects can also be consumed with other build systems like CMake.
Once we want to create a package, it is advised to close VS IDE, clean the temporary build files from VS to avoid problems, then create and test the package. Here it is using system defaults, assuming they are Visual Studio 14, Release, x86_64:
# close VS
$ git clean -xdf
$ conan create . memsharded/testing
...
> Hello World Release!
Instead of closing the IDE and running the command:git clean we could also configure a smarter filter in exports_sources
field, so temporary
build files are not exported into the recipe.
This process can be repeated to create and test packages for different configurations:
$ conan create . memsharded/testing -s arch=x86
$ conan create . memsharded/testing -s compiler="Visual Studio" -s compiler.runtime=MDd -s build_type=Debug
$ conan create . memsharded/testing -s compiler="Visual Studio" -s compiler.runtime=MDd -s build_type=Debug -s arch=x86
Note
It is not mandatory to specify the compiler.runtime
setting. If it is not explicitly defined, Conan will
automatically use runtime=MDd
for build_type==Debug
and runtime=MD
for build_type==Release
.
You can list the different created binary packages:
$ conan search Hello/0.1@memsharded/testing
Uploading binaries
Your locally created packages can already be uploaded to a Conan remote. If you created them with the original username “memsharded”, as from the git clone, you might want to do a conan copy to put them on your own username. Of course, you can also directly use your user name in conan create.
Another alternative is to configure the permissions in the remote, to allow uploading packages with
different usernames. By default artifactory will do it but Conan server won’t:
permissions must be given in [write_permissions]
section of server.conf
.
Reusing packages
To use existing packages directly from Visual Studio, Conan provides the visual_studio
generator.
Let’s clone an existing “Chat” project, consisting of a ChatLib static library that makes use of the
previous “Hello World” package, and a MyChat application, calling the ChatLib library function.
$ git clone https://github.com/memsharded/chat_vs
$ cd chat_vs
As above, the repository contains a Visual Studio solution in the build
folder.
But if you try to open it, it will fail to load.
This is because it is expecting to find a file with the required information about dependencies,
so it is necessary to obtain that file first. Just run:
$ conan install .
You will see that it created two files, a conaninfo.txt
file, containing the current
configuration of dependencies, and a conanbuildinfo.props
file, containing the Visual Studio
properties (like <AdditionalIncludeDirectories>
), so it is able to find the installed dependencies.
Now you can open the IDE and build and run the app (by the way, the chat function is just calling
the hello()
function two or three times, depending on the build type):
$ build\ChatLib\ChatLib.sln
# Switch to Release
# MyChat -> Set as Startup Project
# Ctrl + F5 (Debug -> Run without debugging)
> Hello World Release!
> Hello World Release!
If you wish to link with the debug version of Hello package, just install it and change IDE build type:
$ conan install . -s build_type=Debug -s compiler="Visual Studio" -s compiler.runtime=MDd
# Switch to Debug
# Ctrl + F5 (Debug -> Run without debugging)
> Hello World Debug!
> Hello World Debug!
> Hello World Debug!
Now you can close the IDE and clean the temporary files:
# close VS IDE
$ git clean -xdf
Again, there is a conanfile.py
package recipe in the repository, together with a test_package
.
The recipe is almost identical to the above one, just with two minor differences:
requires = "Hello/0.1@memsharded/testing"
...
generators = "visual_studio"
This will allow us to create and test the package of the ChatLib library:
$ conan create . memsharded/testing
> Hello World Release!
> Hello World Release!
You can also repeat the process for different build types and architectures.
Other configurations
The above example works as-is for VS2017, because VS supports upgrading from previous versions.
The MSBuild()
already implements such functionality, so building and testing
packages with VS2017 can be done.
$ conan create . demo/testing -s compiler="Visual Studio" -s compiler.version=15
If you have to build for older versions of Visual Studio, it is also possible. In that case, you would probably have different solution projects inside your build folder. Then the recipe only has to select the correct one, something like:
def build(self):
# assuming HelloLibVS12, HelloLibVS14 subfolders
sln_file = "build/HelloLibVS%s/HelloLib.sln" % self.settings.compiler.version
msbuild = MSBuild(self)
msbuild.build(sln_file)
Finally, we used just one conanbuildinfo.props
file, which the solution loaded at a global level.
You could also define multiple conanbuildinfo.props
files, one per configuration (Release/Debug, x86/x86_64), and load them accordingly.
Note
So far, the visual_studio
generator is single-configuration (packages containing debug or release artifacts,
the generally recommended approach). It does not support multi-config packages (packages containing both debug and release artifacts).
Please report and provide feedback (submit an issue in github) to request this feature if necessary.