Using Visual Studio 2015 Enterprise on Windows 10 64-bit. Working with a solution which contains a bunch of C# library projects.
When building the solution, then building it again, then repeating this, each time there are a handful of projects which build every time. There have been no changes to any of the source files, yet VS still wants to build these projects.
Anyone have any tips on debugging the build dependencies to figure out WHY it wants to build these projects each time?
Related
We've upgraded from Visual Studio 2015 to 2019 and did an enhancement using VS 2019. Now, we have in the verge of build and packaging the application in build machine, but the problem is, our team leader is saying that we can use Visual Studio 2015 on the build machine to build the project and when I told him, what is the use of upgrading 2015 to 2019 and he told me that it doesn't matter.
Now, I need few good reason to prove that building a project using VS 2015 which we've developed using 2019 is not a good idea. Can someone let me know few points?
Thanks.
Now, I need few good reason to prove that building a project using VS
2015 which we've developed using 2019 is not a good idea. Can someone
let me know few points?
For your situation, I must first declare that you would better use build engine of VS2019 to build VS2019 projects. And as we know, the build engine of VS supports downward compatibility which means the higher version can build the projects of lower version. For an example, you have a lower version projects which created by VS2015, you can use the VS2017,VS2019 to build this project successfully.
Therefore, it is not recommended to use the old version tool to compile the new version of the project.
In more detail, the build engine is also based on the content of your current project and the code in the content (each version of VS has slightly different rules for the code being developed and the content of the file) to finally generate the output file based on the rules of the build engine (means the target order, existing in the .props or .targets file of xxx.xxporj).
Like this:
The difference between the rules in different versions of the build tool is the different target commands in these import files
Second, if your project code only uses a few passing statement rules, you can compile using VS2015. However, if you are using some of the language rules that are specific to the higher version, you can only use the build tool in VS2019, and you will inevitably use its rules for projects that you are developing in VS2019.
Third,VS2019 contains some new workloads and new project templates while the old version VS2015 did not have. For an example, VS2019 can creating the new Net Coreproject while VS2015 did not contains the new workload, So build tool for VS2015 cannot build this type of projects. Because of this, some changes in the new release will also have an impact on msbuild. To avoid unprovoked problems, we recommend using VS2019.
In addition, l agree with ToddN. If you think VS2019 is too big and too cumbersome to download to the build server, you can just download the build tool for VS2019. You don't have to download the huge VS IDE because current VS compilation tools can be downloaded separately. When you use it, you only need to install the corresponding project's workload.
My solution consists from C# projects. I need one build definition that builds the whole solution. Most of projects have project to project referencies (like ProjectReference Include=) but some projects have explicit dependencies stored in solution file (ProjectSection(ProjectDependencies) in sln file).
old connect.microsoft.com article
claims that MSBuild ignores order specified in solution "Project dependencies". Are situation the same in TFS 2015? What MSBuild version does TFS 2015 use nowadays?
Does TFS 2015 Team Buider that uses MSBuild order building of projects properly according to dependencies stored in solution file?
It does, at least on solutions I have seen (consisting of 10-15 projects) dependencies never give issues.
Additionally TFS2015 have Visual Studio build step which is run not by standalone msbuild but Visual Studio installed on the build server. Naturally this build step completely replicates your local build behavior.
I have strange issue regarding visual studio 2013 after migrate from visual studio 2010 envinorment. It's about when i do some changes to any of my projects and then rebuilt it, my other's projects which have reference to those dlls are not updating. Do you know how to force visual studio 2013 to update all my projects when some of them change its dlls? Somehow vs 2010 did that.
What i did as additional so far:
- was tried to make project order built and dependency (not working)
The only way it can work for me is to delete dll from certain project and make reference once again.. ;/
think i found out the solution - just for those projects which are referencing to libraries projects, after libraries project/s are changed and built it seems if i do Unload on the project/s which are consuming those changed libraries project/s and then reload + rebuild dll's will be updated.
P.S Still looking for more convinient solution
We have migrated few projects from TFS2008 to TFS2010 by using the method-
1.Attch TFS2008 DB to TFS2010 DB
2.Tfsconfig import
3.Delete the project not required.
There are few projects in the migrated projects which use VS2005. They do not want to do any change in their project and want to use VS2005 to work with migrated projects. We have applied couple of patches in VS2005 and now they are able to access the TFS2010 projects from VS2005.
However we are clueless about the build configuration. We have configured build server for their Collection...now what configuration needs to be changed in TFsbuild.proj to make the build run again.
Is there any more steps required to make the build work?
Any help would be very much appreciated.
Thanks Upfront.
Kabir
If you have not had a build definition for you TFSbuild.proj then you will need to create one. In your build definition, you will need to choose UpgradeTemplate.xaml as the build process template. In TFS 2010 this template is used to run legacy build definitions.
See how to run build with the UpgradeTemplate.xaml here.
I also found this useful post in the MSDN Build Automation forum that tells you the differences between 2010 and 2005 build processes.
Can anyone explain what advantages there are to using a tool like MSBuild (or NAnt) to build a collection of projects versus running DevEnv.exe from the command-line?
A colleague I had worked with in the past had explained that (at least with older versions of Visual Studio) using DevEnv.exe was much slower than the other techniques, but I haven't read any evidence of that or if that is now a moot point now that starting with 2005, Visual Studio uses MSBuild under the hood.
I know one advantage of using MSBuild allows you to build your projects without requiring Visual Studio to be installed on the build machines, but I wasn't sure if there were others.
One reason is because there's much more to building a product than just compiling it. Tasks such as creating installs, updating version numbers, creating escrows, distributing the final packages, etc. can be much easier because of what these tools (and their extensions) provide.
While you could do all this with regular scripts, using NAnt or MSBuild give you a solid framework for doing all this. There's a lot of community support for both, including additional tasks that can be downloaded (such as the MSBuild Community Tasks Project). Plus, there's support for them in numerous third party and open source products.
If you're just interested in compiling (and not the entire build process), you may find one time saving benefit of MSBuild is the support for building with multiple processors.
The obvious answer from my team is that not everbody has visual studio installed, in particular we do not install Visual Studio onto our build/CI servers.
The prime reason for using an external build tool like NAnt or MsBuild is the ability to automate your build process and thus provide continous feedback on the status of your system. Also they can be used for loads of things besides a "pure" build and that's where you really start to get value from them, it's an extremly valuable thing to be able to build and test your application with a single command.
You can also start adding stuff like collection of metrics, packinging of release binaries and all sorts of nifty stuff like that.
As far as C# goes, devenv.exe 2005 runs the compiler in-proc, which may cause out of memory exceptions for sizable solutions. Msbuild resorts to launching csc.exe process for each project. Projects that don't compile with devenv /build work fine with msbuild. Hope you like this reason.
We are experimenting with switching from DevEnv to a tool (Visual Build Pro) that uses MsBuild under the hood and we got a "Reference required to assembly 'System.Drawing..." error for a project which doesn't need it and which builds fine in Visual Studio.
We have a large system consisting of C#, managed C++, and plain old unmanaged C++ assemblies/dlls. There is C++ code that depends on managed C++ code that depends of C# code that depends of managed C++ code that depends on plain old C++ code (whew!). When we were setting up our automated build environment a few years ago we discovered that MSBuild.exe didn't properly handle all of the dependencies that we have.
Working with Microsoft we were able to solve some of the issues but not all of them. If my memory serves me, we never could get the C# assemblies that depended on managed C++ dlls to build. So we ended up making a custom build script that called devenv.exe from the command line and it worked just fine.
Of course, that was with VS2005, it might be fixed now, but the script is still working so we haven't revisited the issue.