I am currently migrating a reasonably large solution from VS2008 to VS2012. To date, this solution has been dependent on a command line build for several build steps, and I want to use the project system properly to execute these build steps. I've been through the various options and decided that a custom build step makes sense in most of the VC++ projects that require it. The solution is a mix of C++, C# & VB.
These tasks include building Primary Inter-op Assemblies and processing output files using third-party utilities, where the input and the output are the same.
I've had some teething issues, but I'm mostly up and working with this approach. The remaining issue is one of deploying these additional outputs to dependent projects.
Consider this; I have a third-party component, which given an input of a.dll produces two outputs, a revised a.dll and a_util.dll. When I have a project that is dependent on a.dll, I now need that project to pull a_util.dll in to it's output too. I was hopeful that the "Treat Output as Content" field on the custom build step in VS2012 would help in this respect, but I'm going by the one-liner in the UI, I can't find any comprehensive documentation on this option. In fact, the MSDN documentation just pretends this option doesn't exist.
If anyone can help explain this option, or an alternative approach, that would be great.
EDIT
At the moment, I am adding a BeforeBuild target to each dependent project to copy the additional outputs into that dependent project. The problem with this approach (while it works) is one of maintenance. Unfortunately if a dependency of this type is missed, it results in a cryptic runtime error.
Here's a link to VS2013 documentation that says:
Treat Output As Content: This option is only meaningful for Windows Store or Windows Phone apps, which include all content files in the .appx package.
Related
I'm building a solution containing .NET Standard 2.0 and .NET Core 2.0 projects (C# and F#) in VS2019 (16.1.1). If I build multiple times without changes the second and subsequent builds should say "Build: 0 succeeded, 0 failed, X up-to-date", but it sometimes rebuilds some projects every time. How do I find out exactly why?
There are many SO questions and blog posts about this, most of them suggesting setting the build log verbosity to "Diagnostic" and looking for "not up to date". I've done that and the string is not found, nor is "not up-to-date" (but "up-to-date" occurs many times). So this appears to have changed in VS2019. I also know about the U2DCheckVerbosity registry setting, but that's only for .NET Framework. Reading through the build log output is unrealistic, as it's over 360 thousands lines, so I need to know what to search for.
Please note, I'm not looking for guesses as to what the problem might be - I'm looking for a way to get VS/the compiler to tell me.
I'm looking for a way to get VS/the compiler to tell me. (For VS2019)
It's hard to reproduce same issue so I'm not sure about the cause of your issue. But as for what you're asking is the way to find up-to-date related info in Output window, maybe you can check the Up To Data Checks option for .net core.
Go Tools=>Options=>Projects and Solutions=>.net core=>Up To Data Checks. Make sure you've checked the Don't call MSBuild if a project appears to be up-to-date. Then change the Logging Level to Info or Verbose.(Choose the suitable level according to your needs)
For the normal .net framework projects or C++ projects, the build output verbosity in build and run would be of great help. But when trying to find the reason why VS consider one .net core or .net standard project is out-of-date, I think we can try this option since its output is more clear.
E.g: (One .net Core project which depends on the Standard project with Info level .net core Up-To-Date Check):
And if you have too many projects in one solution, I suggest you build one project one time instead of build the whole solution so you can locate the cause of the rebuild more easily.
VS writes a file called NETCoreApp,Version=v2.0.AssemblyAttributes.cs into temp folder. If you build several .net core projects, the file gets changed by the other project and your VS thinks the old project is modified and builds it.
Move the generated files into the project to reduce the builds:
<PropertyGroup>
<TargetFrameworkMonikerAssemblyAttributesFileClean>False</TargetFrameworkMonikerAssemblyAttributesFileClean>
<TargetFrameworkMonikerAssemblyAttributesPath>$(MSBuildThisFileDirectory)SharedAssemblyAttributes.cs</TargetFrameworkMonikerAssemblyAttributesPath>
</PropertyGroup>
In VS2019 the option to control logging is:
The default is "None", but honestly "Minimal" is a good setting in general. When set to that level, only a single line is output per project, and only if that project is not up-to-date. That line will explain exactly why the project is considered out-of-date.
It's worth remembering that this is Visual Studio's up-to-date check, which it uses to quickly assess project state and avoid the comparatively expensive call to MSBuild. It is possible, with exotic project configurations, that VS determines your project needs building, but MSBuild doesn't actually build. This is rare, but can be worth understanding if you're debugging issues here.
I've been trying for about 2 weeks now to get a logging library to work with. I've tried Log4cxx, Log4cpp, log4cplus and boost.log. The problem isn't that none of these work for me, it's that I can't figure out how to get them to work at all. I would really like to use log4cxx since I'm working with log4j/logback at work, but I haven't been able to get any of the libraries based on log4j to build. I've been able to build and use the boost library, but boost.log gives me all kinds of linker errors no matter what I try. If anyone could direct me to a step-by-step guide to get one of these libraries working I would greatly appreciate it. Also, I'm using eclipse as my IDE if that matters.
Did you ever get this working? Log4cxx definitely works on Win7. Maybe you could post some of your build errors. Just guessing, perhaps you didn't configure your eclipse project to link with a log4cxx static lib.
Boost.Log works for me quite well (Linux and Windows). It is not a header only library, there is a compiled part that you need to link against. See instructions here.
It also depends on other, non-header, Boost libraries:
The logging library uses several other Boost libraries that need
building too. These are Boost.Filesystem, Boost.System,
Boost.DateTime, Boost.Thread and Boost.Regex. Refer to their
documentation for detailed instructions on the building procedure.
Depending on your platform there may be pre-built versions of the Boost libraries. Otherwise building it yourself is straightforward if you follow the instructions. If you get stuck update your question with where exactly you got stuck and what you're seeing.
I'd recommend Pantheios. It takes some time to build everything when you first download - type make build test and go have lunch - and you have to select the output streams (Pantheios calls them "back ends") at link time, but for coding, it is really simple, e.g.
std::string name;
int age;
pantheios::log_DEBUG("name=", name, " age=", pantheios::integer(age));
It's designed from the ground up for speed - the age won't be converted into a string unless the "DEBUG" level is switched on - and robustness - which is why you can't pass fundamental types directly, and use "inserters" (e.g. pantheios::integer). See this recent blog post by Pantheios' author for more information.
I managed to get log4cxx to work, this was done in Visual Studios 2013 running on Windows 7 OS.
This following is what I did, step by step:
Download the log4cxx ZIP package extract its contents, http://logging.apache.org/log4cxx/download.html
Download apr and apr-util ZIP packages, http://apr.apache.org/download.cgi
Then
manually extract this zip apr-1.2.11-win32-src.zip (the
extracted folder should be named 'apr', if it is not manually rename
it)
manually extract this zip apr-util-1.2.10-win32-src.zip (the
extracted folder should be named 'apr-util', if it is not manually
rename it)
open a command prompt and run the following: cd
apache-log4cxx-0.10.0 configure (this
will execute configure.bat)
We will need to disable to use of the APR ICONV and LDAP support.
In order to do so, we will append the following files manually:
Open apr-util\include\apu.hw. Find the line starting with “#define
APU_HAVE_APR_ICONV”. Change the value to 0 and save.
Open apr-util\include\apr_ldap.hw. Find the line starting with
“#define APR_HAS_LDAP” Change the value to 0 and save.
We need to build the log4cxx.dll, to do so convert *.dsw
to *.cxproj.
Launch Visual Studio 2013 and open log4cxx.dsw.
VS will ask if you like to convert everything. Simply click Yes.
There may be some warnings in the migration report, but nothing that
should prevent the solution from opening.
> The projects xml, apr, and apr-util should build successfully.
If you try compiling the log4cxx project it will most
likely fail with hundreds of errors. This is due to a bug in VC++
which can be worked around.
Move all macros outside (above) the class they are in.
LOG4CXX_LIST_DEF macro is used to define classes. All macros reported in error C2252 will need to move out of any classes. This
may also include moving definitions which are used in the macro.
Next, change all LoggingEvent::KeySet to KeySet (this is no longer nested in a parent class)
> Following this, the log4cxx project should now compile
successfully on your machine.
we work under Linux/Eclipse/C++ using Eclipse's "native" C++ projects (.cproject). the system comprises from several C++ projects all kept under svn version control, using integrated subclipse plugin.
we want to have a script that would checkout, compile and package the system, without us needing to drive this process manually from eclipse, as we do now.
I see that there are generated makefile and support files (sources.mk, subdir.mk etc.), scattered around, which are not under version control (probably the subclipse plugin is "clever" enough to exclude them). I guess I can put them under svn and use in the script we need.
however, this feels shaky. have anybody tried it? Are there any issues to expect? Are there recommended ways to achieve what we need?
N.B. I don't believe that an idea of adopting another build system will be accepted nicely, unless it's SUPER-smooth. We are a small company of 4 developers running full-steam ahead, and any additional overhead or learning curve will not appreciated :)
thanks a lot in advance!
I would not recommend putting things that are generated in an external tool into version control. My favorite phrase for this tactic is "version the recipe, not the cake". Instead, you should use a third party tool like your script to manipulate Eclipse appropriately to generate these files from your sources, and then compile them. This avoids the risk of having one of these automatically generated files be out of sync with your root sources.
I'm not sure what your threshold for "super-smooth" is, but you might want to take a look at Maven2, which has a plugin for Eclipse projects to do just this.
I know that this is a big problem (I had exactly the same; in addition: maintaining a build-workspace in svn is a real pain!)
Problems I see:
You will get into problems as soon as somebody adds or changes project settings files but doesn't trigger a new build for all possible platforms! (makefiles aren't updated).
There is no overall make file so you can not easily use the build order of your projects that Eclipse had calculated
BTW: I wrote an Eclipse plugin that builds up a workspace from a given (textual) list of projects and then triggers the build. That's possible but also not an easy task.
Unfortunately I can't post the plugin somewhere because I wrote it for my former employer...
I have a number of native C++ libraries (Win32, without MFC) compiling under Visual Studio 2005, and used in a number of solutions.
I'd like to be able to choose to compile and link them as either static libraries or DLLs, depending on the needs of the particular solution in which I'm using them.
What's the best way to do this? I've considered these approaches:
1. Multiple project files
Example: "foo_static.vcproj" vs "foo_dll.vcproj"
Pro: easy to generate for new libraries, not too much manual vcproj munging.
Con: settings, file lists, etc. in two places get out of sync too easily.
2. Single project file, multiple configurations
Example: "Debug | Win32" vs "Debug DLL | Win32", etc.
Pro: file lists are easier to keep in sync; compilation options are somewhat easier to keep in sync
Con: I build for both Win32 and Smart Device targets, so I already have multiple configurations; I don't want to make my combinatorial explosion worse ("Static library for FooPhone | WinMobile 6", "Dynamic library for FooPhone | WinMobile 6", "Static library for BarPda | WinMobile 6", etc.
Worse Con: VS 2005 has a bad habit of assuming that if you have a configuration defined for platform "Foo", then you really need it for all other platforms in your solution, and haphazardly inserts all permutations of configuration/platform configurations all over the affected vcproj files, whether valid or not. (Bug filed with MS; closed as WONTFIX.)
3. Single project file, selecting static or dynamic via vsprops files
Example: store the appropriate vcproj fragments in property sheet files, then apply the "FooApp Static Library" property sheet to config/platform combinations when you want static libs, and apply the "FooApp DLL" property sheet when you want DLLs.
Pros: This is what I really want to do!
Cons: It doesn't seem possible. It seems that the .vcproj attribute that switches between static and dynamic libraries (the ConfigurationType attribute of the Configuration element) isn't overrideable by the .vsprops file. Microsoft's published schema for these files lists only <Tool> and <UserMacro> elements.
EDIT: In case someone suggests it, I've also tried a more "clever" version of #3, in which I define a .vsprops containing a UserMacro called "ModuleConfigurationType" with a value of either "2" (DLL) or "4" (static library), and changed the configuration in the .vcproj to have ConfigurationType="$(ModuleConfigurationType)". Visual Studio silently and without warning removes the attribute and replaces it with ConfigurationType="1". So helpful!
Am I missing a better solution?
I may have missed something, but why can't you define the DLL project with no files, and just have it link the lib created by the other project?
And, with respect to settings, you can factor them out in vsprop files...
There is an easy way to create both static and dll lib versions in one project.
Create your dll project. Then do the following to it:
Simply create an nmake makefile or .bat file that runs the lib tool.
Basically, this is just this:
lib /NOLOGO /OUT:<your_lib_pathname> #<<
<list_all_of_your_obj_paths_here>
<<
Then, in your project, add a Post Build Event where the command just runs the .bat file (or nmake or perl). Then, you will always get both a dll and a static lib.
I'll refrain from denigrating visual studio for not allowing the tool for this to exist in a project just before Linker (in the tool flow).
I think the typical way this is done is choice 2 above. It is what I use and what I have seen done by a number of libraries and companies.
If you find it does not work for you then by all means use something else.
Good luck.
I prefer 2 configurations way.
Setup all common settings via 'All configurations' item in a project properties windows. After it separated settings. And it's done. Let's go coding.
Also there is very good feature named 'Batch build', which builds specified configurations by turn.
Multiple projects are the best way to go - this is the configuration i have most widely seen in umpteen no of projects that i have come across.
That said, it might be also possible to implement the third option by modifying your vcproj files on the fly from external tools(like a custom vbscript), that you could invoke from a make file. You can use shell variables to control the behavior of the tool.
Note that you should still use use visual studio to make the build, the makefile should only launch your external tool if required to make the mods and then follow that by the actual build command
I use Visual Studio 6.0 (Still) due to issues that are preventing us from Migrating to VS2005 or newer. Rebuilding causes severe issues (everything breaks)... so many of us are considering lobbying a migration to GnuC++ moving forward in a structured way to eventually get us off of licensed Visual Studio products and onto Eclipse and Linux.
In Unix/Linux it is easy to build for all configurations.. so I can't believe what a time and productivity sink it is to try and accomplish the same task in Visual Studio. For VS6.0 I have so far found that only having two separate projects seems to be workable. I haven't yet tried the multiple configuration technique, but will see if it works in the older VS6.0.
Why not go for version 1 and generate the second set of project files from the first using a script or something. That way you know that the differences are JUST the pieces required to build a dll or static lib.
Does anyone have experience using makefiles for Visual Studio C++ builds (under VS 2005) as opposed to using the project/solution setup. For us, the way that the project/solutions work is not intuitive and leads to configuruation explosion when you are trying to tweak builds with specific compile time flags.
Under Unix, it's pretty easy to set up a makefile that has its default options overridden by user settings (or other configuration setting). But doing these types of things seems difficult in Visual Studio.
By way of example, we have a project that needs to get build for 3 different platforms. Each platform might have several configurations (for example debug, release, and several others). One of my goals on a newly formed project is to have a solution that can have all platform build living together, which makes building and testing code changes easier since you aren't having to open 3 different solutions just to test your code. But visual studio will require 3 * (number of base configurations) configurations. i.e. PC Debug, X360 Debug, PS3 Debug, etc.
It seems like a makefile solution is much better here. Wrapped with some basic batchfiles or scripts, it would be easy to keep the configuration explotion to a minimum and only maintain a small set of files for all of the different builds that we have to do.
However, I have no experience with makefiles under visual studio and would like to know if others have experiences or issues that they can share.
Thanks.
(post edited to mention that these are C++ builds)
I've found some benefits to makefiles with large projects, mainly related to unifying the location of the project settings. It's somewhat easier to manage the list of source files, include paths, preprocessor defines and so on, if they're all in a makefile or other build config file. With multiple configurations, adding an include path means you need to make sure you update every config manually through Visual Studio's fiddly project properties, which can get pretty tedious as a project grows in size.
Projects which use a lot of custom build tools can be easier to manage too, such as if you need to compile pixel / vertex shaders, or code in other languages without native VS support.
You'll still need to have various different project configurations however, since you'll need to differentiate the invocation of the build tool for each config (e.g. passing in different command line options to make).
Immediate downsides that spring to mind:
Slower builds: VS isn't particularly quick at invoking external tools, or even working out whether it needs to build a project in the first place.
Awkward inter-project dependencies: It's fiddly to set up so that a dependee causes the base project to build, and fiddlier to make sure that they get built in the right order. I've had some success getting SCons to do this, but it's always a challenge to get working well.
Loss of some useful IDE features: Edit & Continue being the main one!
In short, you'll spend less time managing your project configurations, but more time coaxing Visual Studio to work properly with it.
Visual studio is being built on top of the MSBuild configurations files. You can consider *proj and *sln files as makefiles. They allow you to fully customize build process.
While it's technically possible, it's not a very friendly solution within Visual Studio. It will be fighting you the entire time.
I recommend you take a look at NAnt. It's a very robust build system where you can do basically anything you need to.
Our NAnt script does this on every build:
Migrate the database to the latest version
Generate C# entities off of the database
Compile every project in our "master" solution
Run all unit tests
Run all integration tests
Additionally, our build server leverages this and adds 1 more task, which is generating Sandcastle documentation.
If you don't like XML, you might also take a look at Rake (ruby), Bake/BooBuildSystem (Boo), or Psake (PowerShell)
You can use nant to build the projects individually thus replacing the solution and have 1 coding solution and no build solutions.
1 thing to keep in mind, is that the solution and csproj files from vs 2005 and up are msbuild scripts. So if you get acquainted with msbuild you might be able to wield the existing files, to make vs easier, and to make your deployment easier.
We have a similar set up as the one you are describing. We support at least 3 different platforms, so the we found that using CMake to mange the different Visual Studio solutions. Set up can be a bit painful, but it pretty much boils down to reading the docs and a couple of tutorials. You should be able to do virtually everything you can do by going to the properties of the projects and the solution.
Not sure if you can have all three platforms builds living together in the same solution, but you can use CruiseControl to take care of your builds, and running your testing scripts as often as needed.