I have a VS2010 solution with couple of Qt-based projects. Every time when i modify files from one certain project, generated files (moc_*.cpp ones) changes its properties to be excluded from build. Checked all the available properties but couldn't find anything related to the issue (didn't tried to recreate the project from scratch though).
Any chances to fix that?
There is a related question.
First you have to check the MocDirectory in the Qt Project Settings.
Originally, I set it to the wrong value $(Configuration) and encountered the same problem as you.
After I changed it to $(ConfigurationName), the problem disappeared.
The reason that when the wrong value is set, MocDirectory points to the same directory for different project configuration (e.g. debug and release). When the project is built, it will excluded the generated files in MocDirectory with respect to other project configurations. Since all the configurations refer to the same MocDirectory, all generated files will be excluded.
Related
There are a number of post in relation to Visual Studio building projects when not necessary. However, none seem to cover this particular issue.
I'm running Visual Studio 2012 Professional Update 4.
In my solution, I have a unit test project that has a project reference to a BizTalk Transforms project. This in-turn has a project reference to a BizTalk schemas project.
Every time I choose to run a unit test, the whole solution is built, even though no changes have been made.
The first line displayed in the build window is as follows:
Input file
'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\FFF.Enterprise.WareHouse.Schemas.btproj.user'
is modified after output file
'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\bin\Release\FFF.Enterprise.WareHouse.Schemas.pdb'.
Note: it seems to be the .user file that's causing the rebuild.
Does anyone know how to prevent this? Strange but I only seem to be getting the problem with BizTalk proj files. I am seeing this behavior across multiple solutions but the problem file is always identified as a btproj.user.
This screencast illustrates the problem: screencast link
You should remove the *.user file from your source control.
These files store user specific settings and should never be checked into source control.
I had the same problem. BizTalk projects insist on updating the btproj.user file on every build, resulting in a full rebuild every time.
I solved the problem with the following workaround: Set the ACL Write Flag on Deny. The build cannot update the file and the projects are only build when actually needed.
In my case build time went from 10 minutes to 2.
If you have just opened the solution, even if nothing has changed since the last time you built, if you click Run All, it will as per the description in Test Explorer do a build.
Sorry about the newbie question but I could not find an answer anywhere: I have a Visual Studio 2010 project (C#) with several dependencies on other projects in the same solution. When I debug the project and try to step into code in one of the dependencies, it steps over instead. Also, it seems that it is using a previous, installed version of the dependency instead of using the one in the solution.
How can I make it use the one in the solution and allow step-into?
Figured it out.
The dependencies' compiled versions were installed in the GAC - needed to take them out first.
Needed to turn on Tools->Options->Debugging->General->Enable Just My Code.
Needed to set Copy Local to True for each dependency in the target project.
Like everyone here pointed out, needed to re-build all dependencies first, in Debug mode.
Thanks everyone for your help!
When you add the projects as references, add them using the "projects" tab (of the "add references" dialog) instead of adding them as binary DLLs.
A project's output is only copied to the referencing project's bin folder if the dependent project is build. If the project is used in more than one solution, it may have been compiled previously but it won't update projects in the open solution. If the source is unchanged relative to the binary files, then the project is not compiled and the bin folder is not updated. Use Rebuild or Clean after opening the solution to ensure the projects are in sync.
Also check in Configuration Manager that all the projects have a Build checked.
I have a solution with 40 projects in it. I've recently reconfigured output path for each of these projects to this value:
..\Output
Change was made in *.csproj files for every build configuration.
This change did what was expected (gather all compiled assemblies into one folder) but unusual side effect is - every time I hit F5 Debug, portion of the (around 40%) assemblies always gets rebuilt. I have tested this several times without any changes to the projects themselves.
Once I undid changes build behaved as before.
I need help resolving this issue.
This issue is solved by changing the project files, cleaning solution, deleting all bin folders by hand, restarting Visual studio and rebuilding everything.
I would guess that the assemblies that get rebuilt are referenced from the project you are trying to build? Check the references in one of the projects, and see if this is correct. If so, you might try to adjust the properties for each reference, such as "Copy Local", and/or "Specific Version"; maybe each project "thinks" it needs to rebuild the other projects it references in order to achieve the same version number or something like that.
I have a largeish solution in Visual Studio 2008 (around 30 projects, all C# and Script#), including some test projects.
When I start the application or run my tests, way to often Visual Studio rebuilds everything rather than just the changed parts and their dependencies.
If I don't change anything at all, it will not rebuild, but as soon as I change any file in any project, everything in the entire solution will be rebuilt, even the 90% of projects which were not affected at all.
Does anyone have an idea of what the problem can be, or provide me a hint of where I can start troubleshooting it?
Edit: To clarify, all projects in the solution are rebuilt, even those which are not directly or indirectly dependent on the project that has actually been modified. Even those which the modified project depends on, so it can't be a simple project reference issue.
The build sequence is determined by the project references (dependencies).
To avoid to build the projects depending on the project you've edited, you can use Build Current under the menu Build.
I setup CTL+B as shortcut to Build Current which saved me a lot of time than F6. Everytime I just use CTL+B after I save a file.
Hopefully this will help.
You can use the configuration manager to set up a specific config for your sln that will only build the projects you specify. You can find it under Build->Configuration Manager
Here's my specific scenario: Using VS2010, Pex and TFS2008, generated moles files are getting automatically added to source-control (TFS).
Pex adds a "project_name.moles" file to your test project and then autogenerates 3 files at build time: project_name.Designer.cs, project_name.Moles.dll, and project_name.Moles.xml. I want to keep the *.moles files in TFS (it's source code) but I don't want the 3 generated files to be in TFS (they are still part of the project, but they are generated when first built on a new system).
There are two reasons I need this behavior:
1. It's not a good idea to store generated code in source-control (let's not debate the merits of that here).
2. Specially, the DLL file is BAD because every time someone builds, all moles files are regenerated and thus all files are checked-out and DLL files are checked-out EXCLUSIVELY (non-mergable) and so other people can no longer build on their local box.
The Pex/Moles team are working on this but the solution is still likely several months away.
Is there a csproj property that can be assigned to these project files so that they are in the project but not managed by version control? I don't mind hand-editing the csproj file.
Moles will not be adding any files to the project in the next version (v0.94). It will use MSBuild to generate the assemblies on demand.
I think it depends more on the version control tool than Visual Studio, as usually you can set up some kind of filters in your version control configuration in order to exclude some files/paths.
E.g. if you use Mercurial/Hg, you can (and should) edit your repository .hgignore file and specify e.g. to exclude all *.moles files and the whole sub-tree MolesAssemblies\*. I guess other version control systems have similar options.