Mirroring source code to 2 different Team Foundation Servers - c#

my Friends. I have my own TFS where I'm developing an application (only me). Now I would like to SHARE IT and make its source code public at Codeplex. So I went to the site, created a project and chose TFS as the source control system.
The problem comes that, in order to publish the code, I would have to change my current source control and it's a really tedious task. I would have to mirror the contents of my project to the Codeplex TFS to keep it updated. Sounds difficult, but...
... is there any way to replicate the contents of the TFS so my code can automatically be shared while keeping my current TFS setup without much hassle?
Thanks!

Don't know about a regular TFS workspace, but if it's a GIT repository, you can define multiple "remotes" in your local GIT repo, so that it pushes changes to both your local TFS and Codeplex

Related

Is there a way to avoid installing VS extensions like "SQLite for WinRT" for each teammember?

We are developing a Windows Store C#/XAML application that has to (among other things) interact with SQLite database and display Bing maps for specific GPS coordinates.
"Official" way to do this seems to be to install two Visual Studio extensions - SQLite for Windows Runtime and Bing Maps SDK. I have two problems with this approach:
It is necessary to install them separately on machine of each and every team member. With new PCs, VS reinstallations and people coming and leaving the project, this can get tedious really quickly.
Updates. Let's say I install a specific version of an extension and commit the project referencing that specific version. Then, a new team member comes in and I need to install the extension to his PC as well. However, in the meantime, Microsoft has released a newer version of the extension and I am unable to download the older one - and now, because of one new person, everyone has to update their extensions, too.
Ideally, what I'd like to do is to somehow put these extensions to SVN. That way, they are stored in one place only and there is no hassle with constant installations and updates. I was able to extract .dll files from SQLite extension, but with the Bing Maps, there is a .winmd file as well as a native .dll. I am unable to reference .winmd directly, and loading it dynamically is, as I've come to understand, not possible.
Is there some way to achieve what I want and avoid all outlined problems? I hope I am overlooking something, because I can't believe Microsoft would decide on something so stupid...
Yes, there is a way.
You will find the explanation and an example in this blog post by Oren Novotny: http://novotny.org/blog/how-to-use-extension-sdks-per-project
Kudos to the writer of this post, it saved me tons of work.
I had the same problem when trying to do CI with TFSBuild service in Visual Studio Online in a project that had Bing Maps. We can't install anything in the integration server because is cloud based, so I had to do a very long search to find the solution. It involves modifying the .sln file and putting the files in source control maintaining a precise folder structure, but when you do all this correctly it works like a charm.

Using Team Explorer to add an existing project Team Foundation Service

I'm just getting into Team Foundation "Service", this in turn is my first exposure to Team Foundation Server.
Im a bit muddled about a couple of things. I have existing C# solutions, some comprising 30 C# projects. I want to put them under the version control of TFS. So a couple of questions:
Does version control only "apply" at the c# solution level. I dont seem to be able to add an individual project to TFS, only a solution.
Do all C# projects need to sit beneath the C# solution in an NTFS directory hierarchy? I cant seem to add a c# project to an online TFS collection unless that C# project has the C# solution folder as its root.
This is not always the case for me since I use solutions as "views" depending upon the aspect of the application I am developing.
So do I need to change my local layout to work with TFS and version control or can I somehow link projects from disparate local location to a single TFS repository?
All my Team Explorer Connect icons always appear in black?
And yet all the documentation and other posts I see on the net plus here ion SO have red/orange icons.
Do this mean I'm disconnected or something else? Also, I don't get the "Publish" option in the context menu. Instead I have to do what feels like the long way round buy doing a local commit then go changes/commit/push.

Automatic patch building and deployment of .NET application

The question in short form and then the explanation
We want to create patches and include only files which have changed in the build due to some bugfixes for a dotnet application. The patches should get automatically built in the Continuous Integration process involving SVN, Cruisecontrol.net and msbuild.
We have a scenario here:
We want to maintain a .net application which runs on remote servers using continuous integration. The source code is in a SVN and has 3 different repositories for DEV, QA and PROD.
Our developers do new bug fixes almost everyday and merge the changes into the dev repository after their initial testing and satisfaction.
The code after a certain problem is solved or a feature has been added is then merged into the QA repository.
The QA code is built and tested on QA machines manually.
After the QA testing we merge it into PROD. With it the QA also makes new patches for the files which have to be replaced or changed manually. Then the patches are deployed on a staging server. On which it is tested until perfect and then the patches are deployed on actual remote servers.
In search of continuous integration we are now trying to use a mix of CruiseControl.net and msbuild to do the process. The process is good until the stage where we have to generate patches from the QA builds automatically. After the patches are generated we will put them on a ftp server and from their they will be downloaded to the staging server to be tested.
The problem i.e. the generation of patches from the new build has a few aspects. The solution file for the application has many projects and the dlls are copied using postbuild events to the startup app bin folder. So we have a specific directory structure in the actual application which itself is a combination of 6 solutions which are more or less independent of each other.
The way we are trying to create the patches is we are searching the logs of svn to find which files have changed. Then we are parsing it finding the project name. Then we are copying all the files from the bin directory of that project to the patch folder in the specific manner in which the release has them by using a mapping file which has all the files of the application in it.
So can anyone please suggest a much better or easier way to make a patch provided we have svn and the cruisecontrol.net. Or any other opensource tool to do that.
hope the problem is clear
This whole process, in general, goes against established best practices. This is not necessarily a bad thing if you have good reasons for it, but I don't see them here.
In essence, you are not using QA and DEV environments to secure the stability of production. Worse, you use different source trees to build code for them. This introduces new points of possible failures into the deployment process.
A standard way of approaching this would be to have a single SVN code tree - tag a version when it is released to QA (using already built binaries!), possibly tag it again when releasing to PROD. Don't re-build the binaries, use the ones that you actually tested!
If your Msbuild task is performing a build instead of a rebuild then the date/time of unaffected dlls will not have their modified date changed.
I would suggest this for the following reasons:
Msbuild will update the modified date for any assembly which has been affected by a change - I.e. an interface change?
the assembly is what you want to deploy, so check this rather than the source for modifications. Otherwise you need to know the build process (won't change) - I.e. Souce file locations, references etc.
Your deployment would just include the dlls from the build directories where the modified date >= BuildDate.
I agree with skolima about the recommanded build & patch process. You should create your patches from your initial tags plus the modifications and then create a new version which have to be deployed in all environments.
In my company, we are using this method :
Each successfull build are automatically tagged by our CI Server
When a patch is needed for a specific version, the programmers copy
& check-out the tagged version and apply fixes on it
Then we have a specific "Patch" build on our CI Server which do
exactly the same thing as a normal build with a "Patch" flag and point to the patched sources
The deployment target is the same, the build process is the same, only sources changes.
The plus is the patches have their own build history on the CI because they are builded separately but are treated as normal builds.
Anyway, if you want to automate a patching processes between two repositories via your CI, ihmo you have to create specific MSBuild tasks to do this. You can either try to merge the changes between them or check the SVN diff & patch commands.

Source control for Visual Studio that doesn't require a server?

Can anyone recommend a source control solution for Visual Studio? I am going to be the only person using it, I just need something to back up my data every so often or before I undertake a big change in the software. I tried AnkhSVN, but this requires an SVN server. Is there anything that can be used locally that takes the pain out of copying solution folders manually?
With Subversion you can create local, file-system-based repositories for single-user access.
Probably the easiest way to use subversion (on windows) is to install TortoiseSVN. To create a repository, you simply create an empty folder in the location where you want the repository to be, right click that folder and select "TortoiseSVN -> Create repository here".
It is even possible (but not recommended) to create such a repository on a network share.
You can then access local repositories using a file-URL e.g: file:///D:/Projects/MyRepository
If you later find out that you need a server (e.g. to give other users access to the repository), you can easily install svnserve on a server and move the local repository to that server.
Just for completeness: as others have noted, there are several good clients for subversion (personally I'm using mainly TortoiseSVN and AnkhSVN):
the subversion command line binaries
TortoiseSVN (free, integrated into windows explorer)
VSFileExplorer (free, gives you an explorer view inside Visual Studio and a allows you to access TortoiseSVN from there)
AnkhSVN (free, integrated into Visual Studio)
VisualSVN (commercial, integrated into Visual Studio)
VisualSVN Server (free, a SVN server with a nice GUI)
Funny nobody mentioned Git just yet. Granted, it does have a learning curve, but I've been using it successfully within Visual Studio for the past year. Both commandline and with a GUI (GitExtensions).
Download Git for Windows from here.
Since it is a DVCS, it doesn't need a server. You can work against your local repositories publishing them to the world when needed (check out Github).
You can use AnkhSVN (or any other SVN client) without a server. Just create a repository on your local disk and then point your working copy to it using a URL like file:///C:/Repositories/repo.
AnkhSVN has improved a lot, but I prefer VisualSVN myself. I think its interface is a little easier to work with (especially if you're used to TortoiseSVN, which it is based on) and it will handle things like automatically setting your build folders as ignored. It is commercial, but it is inexpensive.
You can use Mercurial. It's free, fast and easy to use.
I use it for my personal projects.
VisualSVN can operate without SVN server/
SVN is the way to go. I would look at using the VisualSVN plugin rather than anksvn as it is much more modern and worth every penny.
In a similar situation I'd go download and install Git Extensions. That's all.
That gives you a world-class revision control system (the same one used for the Linux kernel), integrated into Visual Studio and Windows Explorer. No server is required. However, it is fairly easy to set one up later if you want one.
I'm pretty sure that you can create a local repository with Tortoise SVN and use it with ankhSVN without a server.
I use Bazaar with Visual Studio. It does not have Visual Studio integration but it is easy enough to issue commands from the command prompt in a separate console.
You can use Dropbox with SVN, which is free. Sign up for one here. If you didn't like that first article, here's another one. You can pretty much google SVN Dropbox and you'll get all the information you need if these two posts are missing anything.
The advantage of using a Dropbox over local SVN is that you'll be able to get to your dropbox from anywhere, as opposed to only being able to SVN while at home.
They are a lot of cheep or free (for small teams) hosted source code control system. So if you wish to advoid running your own server rathern then not use a server at all, you should look at them.

How do I set up an ASP.NET build server?

I want to create an ASP.NET build server for the first time since I've never used it.
Does anyone have a tutorial or resource on how to make an ASP.NET build server?
Or can anyone tell me how it's done?
If by "create" you mean "setup a build server" then I suggest you take a look at TeamCity from JetBrains.
TeamCity is a multi purpose build server and can be used to build ASP.NET projects as well. You can get up and running for free, and its very easy to set up, compared to CruiseControl.Net.
Take a look at MSBuild to see how to do specific ASP.NET build stuff.
MSBuild reference
How to use MSBuild to do ASP.NET compilation (video)
You might need something from the msbuildtasks open source task collection
If you really want to create your own build server from scratch (but why?), I can't help you.
You could make a build server using CruiseControl.NET which can build your project.
CruiseControl.Net Tutorial – Part 1
CruiseControl.Net Tutorial – Part 2
There is no ASP.NET build server as such.
Do you have a one-click build script? If not, you should create that first. Once you are able to run a single command and get a complete build, then it is easy to set up CruiseControl or some other build server.
Given the strength of the build servers out there it's really not sensible to spend any time developing your own.
You will, however, need at the minimum
a one-click build script
a source code repository (e.g. Subversion, TFS, or even [shudder] SourceSafe)
a server to use as a build box (I use a virtual image)
You may also find a one-click deployment script written using something like Powershell to be useful, too.
Note that a very effective alternative to CruiseControl.NET and TeamCity is Hudson. Although it's written in Java it's ridiculously simple to get going with a J2EE server like Tomcat.
The key strength of Hudson is the range the plug-ins, which allow you to monitor most version control systems and then not just build (through MSBuild or even the command line) but also run unit tests, acceptance tests, and so on.
You might look at Web Deployment Projects -- they allow you to build your site and merge all DLLs into a single file, for a fully pre-compiled site. You can use it with MSBuild.
An option on the automation side is Team Foundation Server's (TFS) automated builds. TFS also includes source control, bug tracking and many other features you may or may not need.

Categories