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.
Related
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?
I've been working in an engine in Visual Studio 2012 that supports rendering with Direct3D 9 and Direct3D 11. However I'm getting some new people to help with the project and they would prefer to work on Visual Studio 2010 because that's the version they own and use. So I decided to convert the project to be built with VS2010's v100 platform toolset.
I'm getting close to getting it to work but I can't include DirectXMath.h, necessary for the DirectXTK and some utility functions I'm using. It's part of the Windows 8 SDK and included in VS2012, but VS2010 doesn't seem to find it.
Anyone knows how to get it to be included using environment variables so that it works for everybody on the team, and in a way that works on Win7 too?
Thanks.
To make new teammates be able to code in VS2010 you have several options:
You don't need to change platform toolset to old one and rewrite your codebase. VS2010 developers can just install Windows 8 SDK, and use v110 toolset. To help them, configure "VC++ directories" in project properties as pointed in this article (change macro variables, which points to old Windows SDK, to explicit locations of new Windows SDK):
In “Executable Directories” replace $(WindowsSdkDir)binwith$(ProgramFiles)\Windows Kits\8.0\bin\x86`
In “Include Directories” add $(ProgramFiles)\Windows Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared at
the beginning and remove $(WindowsSdkDir)include
In “Library Directories” replace $(WindowsSdkDir)lib with $(ProgramFiles)\Windows Kits\8.0\lib\win8\um\x86
In “Exclude Directories” replace $(WindowsSdkDir)include with $(ProgramFiles)\Windows
Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared
When targeting x64, replace x86 with x64
If you really want to downgrade toolset from v110 to v100, then you will need to make use old standalone DirectX SDK. Before, Windows SDK and DirectX SDK was separate. They was merged since Windows 7 SDK. When merging, Microsoft decidede to remove some stuff and also renamed some files, for example, standalone SDK contains math in #include <xmmath.h>.
You can combine both: create multiple project/platform configurations and inmplement conditional compilation via #ifdef where VS2010 configuration will fail to find headers/compile. For example you can use C++11 features in VS2012 branch of code, but in VS2010 branch you use only C++03 features.
I would prefer first option, but it is up to you to decide.
P.S. As far as I remember, project files from VS2012 (.vcxproj) cannot be opened in VS2010 (it knows only .vcproj), so you cannot share it. You will probably want to install VS2010, make .vcproj and maintain both files. It can be pain when you change project options in one, and forget to change in other, so be careful. Also, consider to move all your team to single IDE, or at least single build system (for example, CMake).
Happy coding!
we have our business apps and size is 64 MB. every time add new functionality or change existing one then we rebuild our setup and deliver to client. so this means every time we are delivering 64 MB or more than that to our client.
we have our main win form project and also there many other class library project in our project solution. i am looking for easy way out to deliver only changes to our client.
may be changes could be there in our win form project or could be there in any class library.
so wherever changes made i just only deliver changes through setup and i want just client would install that setup or run any exe file and could see the changes we made in code.
i create setup with VS2005 setup creation option. how suggest me the best option for creating patch like apps which any client just install and get the changes in his apps. give me the best idea to implement in detail. thanks
When using Wix to generate an installer for your project, you can use it to also generate a patch file which will update only changed files.
Visual Studio 2005 setup projects don't really support Patch building and such. It's meant as a rudimentary solution for building installers. Wix, however, is what Microsoft uses internally to build the setup experience for Visual Studio 2012 and other products. There is a very extensive walk-through available here.
Wix does come with a steep learning curve. Would you have been using Visual Studio 2010 or 2012, then you could take advantage of a couple of templates that make it much easier to build a setup for a given type of application. I don't believe these will work with Visual Studio 2005.
This book might also guide you.
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.