I saw the suggested link :
What is the difference between a "build" and a "rebuild" in Visual Studio?
in stackOverflow but theres something strange :
I have project with many library dlls. ( projects)
If i add even a space into one *.cs file , and press build on th project - it scans all
the files in the project ( i see some outbput message for the other files - meaning that it scans them)
but in the article it says - ONLY THE CHANGED FILE
my inspection is : ALL THE SPECIFC PROJECT FILES WHERE THE ALTERED CS FILE
p.s. : what about reference to other projects? Does they always rebuild ?
i.e. : Project DLL A has reference to Project Dll B
when i Build A - does B also REbuilds ?
Rebuild is a COMPLETE "Clean" (remove previous binaries) and Build each project, as per the order of Dependency
Build is based on changed files + Dependency
The fact that it scans all projects in your solution when you put a space to a *.cs file implies that this particular file is in a Core project where other projects are dependent upon
Project DLL A is built will trigger a build on Project B, since B is dependent
Related
I work on the project that I have inherited from another developer. It is mix of VB.NET & C#.
Solution is made of multiple projects: Config(start-up project),Common,Agent + project StdPlugin under Plugin folder. (Plugins are .dlls that are loaded during runtime).
For non-plugin projects, output path is set to bin\Debug\. For Plugins projects output path is set to Config\bin\Debug\Plugins.
After the project is compiled, Config\bin\Debug\ has all .dlls +.pdbs and .exe for all my projects. However, Config\bin\Debug\Plugins also contains copies of all project .dlls + .pdbs and .ddl + .pdb for StdPlugin project. In other words, I am getting duplicates. On top of that, when I run Build->Clean Solution, Config\bin\Debug\ is being cleaned out, but Config\bin\Debug\Plugins is not.
Some clarifications: 1. Project is build for debugging. 2. I noticed above issues while investigating The source file is different from the module was build issue that affects the Reader project. It would not stop on breakpoins in Reader project.
I'm using visual studio 2010, and its a C++ solution with multiple projects. I have project A which has reference to project B(Properties->Common Properties->Framework and References). Project C references project A.
Now the build order is B->A->C. C now indirectly references B, is it required that we should manually add Project B as reference to project C?
I want to make sure that when project C is built project B should automatically be built if any changes were made to it and it is not rebuilt yet.
Building your Solution should always build Projects that have changes.
A circular dependency is created if you try to make B->A->C->B. You can have circular dependencies in VS but the build order must be managed manually. See this post.
If a Project references an assembly and not the Project that builds that assembly then VS does not build the dependent Project. If the Project references the Project that builds the dependent assembly then any changes to the dependent Project are built before the target Project. This is the default behavior in VS. That behavior can be changed or managed using the 'Build Dependency' dialog.
It seems that since VS2010 and MSBuild 4.0, VisualStudio and MSBuild are able to resolve and build project references that are not located within the solution.
Let us create an example to be more concrete. Create a solution called Solution1 with a C# project named A and another project called B. In project B, add a reference to project A. Now create a new solution called Solution2 and click "Add Existing project" and select Project B. There is a warning that can be seen in Solution Explorer and the Warning List.
The trick is that even with "warning as error" we are able to build Solution2.sln. Actually, project A is found
and built by Visual Studio or MSBuild. Let us verify this by opening a VS2010/VS2012 command line and execute the following commands:
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA is effectively built and worse: the warning mentioned above is not even raised there. With previous versions of Visual Studio such situation could not happen (I have tested it with msbuild 3.5 and VS2008).
However, in our situation we would like to prevent such things. Indeed, we have a large source repository with several solutions and many committers. We are reorganizing our dependencies aiming finally to the extraction of smaller repositories. Meanwhile, we do not want developers to add hidden project dependencies without seeing it. We would like to allow only project references "inside" a solution, leaving other dependencies to assembly references.
So the question is "Is there a way, to prevent such solution such as Solution2 to build ?". Ideally, it should not compile with both VS2012 and MSBuild. However a solution involving only the MSBuild command line would do thanks to our Continous Integration.
edit I checked Microsoft.Common.Targets and there does not seem any way to achieve what you want. Either project references are built, or they are not (this is for instance influenced by the BuildProjectReferences flag of my original answer). There is no way to build them selectively depending on which solution they are in unless I'm missing something - which is mainly because project references are set on the project level, not on the solution level: in your project file there is an MsBuild ItemGroup named ProjectReferences and that is used. (Actually this makes some sense: if you ask MsBuild to build projectB.csproj, and B says it references A, then no solution comes into play and you could expect it to build A, after all you are referencing it).
Now as I understand it, you want to prohibit referencing across directories whose structure happens to be represented by solutions. If that is the case, and you really need this, you could probably get away with a tool that parses the MsBuild log and looks for lines like
Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
then extract the directory info from it and make the tool raise an error when they do not match. Then incorporate the tool in your CI server and feed it with the msbuild log files.
original answer
Try with /p:BuildProjectReferences=false on the command line. As the name suggests it will disable building of referenced projects. When building solution1, this should not be a problem since projectA will be built anyway as it is in the solution. However when building solution2, it won't build projectA and you'll get a build error.
I have a big VS2008 solution containing >30 VS projects with legacy code. One of these projects (let's call it A) generates a header file, which is needed by a few other projects (for example B). When I go to "Project Dependencies" of the VS solution, I can check project A for project B's dependencies - but VS includes in the project B's linker command line options an additional argument for project A's lib ("A.lib"). Unfortunately, since project A does not create a lib file, this project B will never find one and cannot be built.
Is there a feasible solution for my problem?
Thanks in advance!
Cheers,
Chris
You should set Ignore Import Library in project A.
This option specifies that the (import) library generated by this configuration should not be imported into the dependent projects.
I have 3 C# projects, A (WPF application), B (class library), and C (class library), such that A references B, and B reference C. Project C needs to call some native methods from a C++ DLL via P/Invoke. I added the native DLLs to the C# project and marked them a "Copy to Output Directory". When I build my solution, the native DLLs show up in the output directory for Projects B and C (correctly), but not for Project A. Is there a project setting that allows these to be copied by any project that ultimately references Project C (even if not directly)? Or do I just need to post-build event on Project A to copy this files to my application output folder?
I've looked at Dependencies of references not copied to output directory, but this was referring to project references, so I'm wondering if there is a solution in my case.
I also considered embedding the native DLLs as resources and modifying my DLLImport as in this MSDN article: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.dllimportattribute.aspx. But I get an E_ACCESSDENIED error (I've seen others with this same issue as well, as well as some concerns about triggering antivirus behavior when extracting the DLL to disk). I also noticed the article mentions linking the resource, rather than embedding it. Is this something I need to do as an MSBuild task, rather than through some project properties?
Worst case, I could just add a post-build event to my WPF application that copies the native files, but it would be nice if Visual Studio would recognize that these files should be copied.
I solved this by customizing the output for debug/release mode compiles (on the project properties window) so that all of my projects outputted to the same folder... Much like how an ASP.NET application is published where all DLLs end up in a single /bin folder. That fixed my issue.