I am new to config / build and release management.
We are using VSS for our config management tool and also we are using SharePoint in our project. In VSS we have lot of files like .cs, .snk, .dll, .pdb, .css, .js, .xml etc.
We want to make a build/release as a package for testing that should be an internal delivery. I don't have any idea how to create a build/release package. Can any body give me any suggestion/information how to do this?
One more thing: due to some internal reasons we can not use any free ware or any other software. Is it possible to do this with visual studio?
I agree with Mitch, not possible with VSS only. But...if you don´t wan´t to use TFS (Team Foundation Server) which is the preferred option I would recommend looking at Cruise Control for doing your builds.
The other option is to use some sort of custom MSBuild project to package your stuff together, use WSP Builder to make that process a bit better. The best way to automate this is still to use TFS or Cruise Control to build your custom MS build project.
Related
Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.
Is there a generic programmatic way to use the Visual Studio Source Control Plugin API to check out files, browse repositories and check in files?
I am aware that I can use the TFS API to acheive the same results. However I would like to be able to execute source control commands generically enough without having to worry about which source control is currently used (TFS, SVN, git .. etc)
Note: I am using a Visual Studio package to develop that. So I am in a VS Shell environment
As all SCM systems are built by different vendors there is no such abstraction later. You will need to create custom code for each system and make sure that each systems API is available to do so.
I have my own TFS (visual studio online) and work TFS. In my TFS located my own projects and, in particular, the project with useful utilities. I want to connect it to the work TFS solution, but keep getting an error, which essentially boils down to the fact that you can not connect a project in more than one TFS. Can I achieve the desired result?
No you cannot use multiple Team Foundation Server instances at one time. When you switch a project, you switch to the TFS server that it's stored in.
The recommended way to share utility code like you're talking about is by sharing only the binaries. This can be done using NuGet. You can setup your own NuGet repository and then let your utility project publish to your NuGet server. Other projects can include your NuGet packages just as you use external packages.
You can find a great overview of what NuGet can do here.
We are planning to use Team Foundation Server, but we need to decide whether to use the Visual Studio Team Foundation Server source control plugin or the VisualSVN source control plugin inside Visual Studio.
If you plan to use TFS, go for the TFS Source Control, feature-wise it's as good as SVN if not better (history is managed the same way, branches too, perfs are better).
But where you get benefits in the TFS Source Control compared with SVN is in the integration with Work Item and the rest of TFS.
When you work on a given Task Work Item you can associate your check-ins (then changeset) with the Task, and it's very powerful because you'll have a more project based view than code view.
The Source Control of TFS is the lowest layer of the ALM Solution, you can avoid using it, but you'll lose a lot of things (integration with Work Item, Continuous Integration, Reports, etc.)
If you are planning to use Team Foundation Server, then use visual studio team foundation server source control plugin.
What is the best way to share dll libraries between projects, through VS2010? For example we have made a generic helper library that is useful in everything. However, we need more than one library to be included (which is a separate project in TFS) so branching is not suitable.
We are using Team Foundation Server 2010 for source control. Is there maybe a simple way to integrate these libraries into a new project, so the new project can come "fully buffed" very fast?
What we do now is go through each project, build them, store the dll files, add a new project then throw them in the Bin folder, which is tedious work when you have many libraries.
Have you thought about hosting your own NuGet feed? I use a pre-build script for NuGet for each of my projects which downloads packages for me before the project is built, and, I assume, keeps them up to date.
I don't think that there is some TFS-based solution for sharing binaries between projects. However you can use NuGet to do it for you. Create nuget package for each project (you can create TFS build definition to do it automatically) and publish it to network share. Than add this share as NuGet feed.