Suppose I have a team project in tfs and every time I check in, a new build takes place. Now what I want is that suppose I add a class library to the solution then when I build it a new dll is formed for the class library. So when I check in I want the tfs to just copy only what wasn't there before in the server, i.e.. the class library dll not the whole project again.
Is this possible and how to do this
If you don't add the class library to the version control, it will not be checked in. If it is added by default, you can exclude it when you check in. (in other words, you can always select and add to the source control workspace)
So, you have a TFS 2013 server with a continuous integration build? And you want to set the CI build to be an incremental build?
Assuming you are using the TfvcTemplate.12.xaml build template, then in your build definition you should check out:
Clean Workspace [true/false] which controls whether the build agent pulls down all the code again or only things that have changed.
Clean Build [true/false] which controls if everything is built again or only things that are new (like your class library). This setting only takes effect if Clean Workspace is set to false.
More details
Related
How do I create a package for Umbraco inside Visual Studio? I know that you can create a package inside Umbracos backoffice, but I am not interested in that right now. I just need something simple, like a hello world package
Unfortunately, it's not so simple. It depends what is going to be the package content. If those will be static files, dlls etc. - it's a job for MsBuild and you can use it to gather all the required files and create a package or even distrubute it.
There's a great article by Jeavon Leopold on 24days.in: http://24days.in/umbraco/2014/packaging-with-appveyor/ combined with CI done with AppVeyor.
The challange starts when you want to include document types, datatypes or any other Umbraco-related content there too. And this is really easy to be done with Umbraco Packaging through the backoffice (you just need to select what should be included). Using your custom build and automatic packaging, you need to remember that if anything should be included inside the Umbraco backoffice, it needs to be handled by the creation of those objects in your code (e.g. on application startup events custom handlers) and ensure that if it's not exist it should be re-created etc.
Personally, I suggest you to check how other package creators are handling it, as a lot of packages is open-sourced e.g:
Pipeline CRM (adding custom datatables for future usage in custom section(s)): https://github.com/theotron/PipelineCRM/blob/master/GrowCreate.PipelineCRM/RegisterEvents.cs
Nested Content (custom property editor registration): https://github.com/umco/umbraco-nested-content/blob/develop/src/Our.Umbraco.NestedContent/PropertyEditors/NestedContentPropertyEditor.cs
Personalisation Groups (doument types, nuget packaging etc.): https://github.com/AndyButland/UmbracoPersonalisationGroups
etc.
I have a project in c# which is represent a Ground Station for Aircraft.
I need functionality that when I click on save test, then there is a new project same as the Ground station will be created.
simply just like the visual studio project there is a button to create new project, which is same as visual project.
in other word, I need to create new project from same project with customized configuration.
How to do that?
Do you mean how to create an exact copy of the project you're currently working on?
If so, I'm not sure there's an automated way to accomplish this, but you can just go into Documents\Visual Studio %YourYear%\Projects\%YourProject%, where you replace both of the %-delimited values with your local values. Then, just copy your entire project folder, give it a new name, and open the solution therein. You'll be able to edit it as you see fit without changing the original version.
However, I think you'd be better off using some sort of version control system, like Git or Subversion. With either of these, you can create branches off your master version. You can effect whatever changes you like with these branches without affecting any changes to the original master. If you decide the changes you've made on any branch are worth keeping, you can merge some or all of them with the master and create a new master version.
I have a Visual Studio 2010 solution with many projects and many build configurations in order to make use of Web.config transformations for automatic deployments.
My problem is when a new project is added it does not inherit the existing configurations and thus the build fails on the build server.
As an example, say I have the following custom build configurations:
Development
QA
Production
When a new project is added, it only contains the standard Debug and Release configurations and none of the above custom configs.
The only way I know how to fix it is to manually edit the .csproj file.
What is the proper way to handle this?
Edit I have removed the information about why it fails on the build server because that is irrelevant (and obvious), I just need to know if there is a way to have existing custom build configurations automatically picked up by a new project being added to the solution.
The proper way to handle something you have to do manually on a computer is, usually, doing it automatically. No kidding. All our project files (both C# and C++) are generated: they automatically import the correct property sheets with all build options and all have the same platforms/configurations. It's a relative small amount of work to throw together a program that will save you much more time and effort later on. Basically the Microsoft.Build.Construction namespace has everything you need. To make the program user-friendly we added a small ui on top that lets you drag in directories in which to create projects. So we just run it, create a directory, drag it onto it and add the new project to the solution in VS.
I have a solution in visual studio where one project (.csproj) is set to create an exe.
I would need to create a duplicate copy of this project so that I can name it something different and change the icon for it. (All of the rest of the projects can stay the same)
I am using conditional compilation symbols for that project, but I don't want to create a whole separate solution configuration because that requires expensive rebuilding of the entire solution.
In Visual Studio under Build -> Configuration Manager, you can create a new configuration for your project and clone it from your release build, then in your project properties you can customize it.
For the icon, you'll want to refer to Set a different ApplicationIcon for each build configuration
Create a copy of the project on disk (outside Visual Studio) and add the copied project to the solution. Then you can modify output assembly name, icon. etc..
However better practice would be to perform the necessary operations as postbuild step (e.g. batch/powershell script) as you will have to keep the projects synchronized (added/renamed/removed files, references...)
Copy it somewhere else and change the assembly name and namespace may be on the project property window( right click and property)
I dont know what your trying to accompish but possible solutions:
add post build event that will copy exe / (exe ad dll-s) to another directory
if you use TFS, edit your Build so it will create copys
Cheerz,
I like the idea of automatically versioning my builds but I'm not sure what the right way is to get the AssemblyInfo.cs change back into source control (or should it not go into source control?). Is this something the CI server should be committing automatically for each build?
Using Bamboo at the moment.
We are using Teamcity as our CI server, and it comes with a feature called AssemblyInfo patcher
What this does, is temporarily add the teamcity build number in Assemblyinfo.cs, build generate the artifact and then revert the change. This way the generated artifact has the same version as the build number.
Source control can have the assemblyinfo.cs version entry as the current revision the developers are working on, with '*' as the build number. This can be updated after every release.
Edit 1:
Since you are using Bamboo, here is a link that describes one way of setting the build number in the generated artifact in bamboo, without having to check-in the AssemblyInfo.cs.
I'm sort of confused by your question. If you want the changes to persist you'll have to commit AssemblyInfo.cs after it gets edited by the build job. However, most build systems attempting to solve these problems do not persist the changes. They simply check out the file and edit the local version before kicking off the build task.