The setup:
My team has chosen the migration method of a TFS 2010 to 2013 upgrade: take DB backups of existing instances (using the TFSBackup tool), copy to new servers, restore to new SQL instances (with TFSRestore tool) and install TFS on new app/build tiers with the 'Upgrade' option.
Further context:
I have VS 2010, 2012 and 2013 installed side-by-side on my workstation. I typically don't operate more than one flavor at the same time. And, thus far, I use the same private workspace/mappings in all of them. And depending on what new instance of TFS 2013 upgrade I'm pointing to, the workspace is associated with the correct server value.
What the...?:
The current dress rehearsal went relatively smooth. Post-upgrade, we've encountered no issues with opening/manipulating projects, checking-in files, running team builds, etc. Projects act, as before, like they are bound to source control. However, upon inspecting the *.sln files, the "SccTeamFoundationServer" value is still set to:
http://<oldServer>:8080/tfs/DefaultCollection
...And yet, it continues to operate as if that didn't matter. In fact, looking in the "Change Source Control" dialog, the bindings look quite correct, pointing to the newer instance...
http://<newServer>:8080/tfs/DefaultCollection
Question:
This is a rather curious state the solution files are in now. Can they continue this way if they stay within TFS? Or would it behoove us to have project owners change their project bindings accordingly? Keep in mind, we're talking nearly 1000 project solutions.
And, of course, if one merely unbinds and rebinds to source control, they're going to get the wrong server value unless they first update the proper SccTeamFoundationServer value in the *.sln file by hand.
Related
I am new at using tfs online and create projects. When I am creating a project on TFS online platform, and connecting from visual studio. So I need to map project on my disc. And I see a workspace that has same named my computer name. Does visual studio creates a workspace on visual studio for every tfs project? What is the goal of workspaces?
A workspace represents a mapping between a location in source control ($/SomeTeamProject/SomeFolder and a location on your computer (C:\SourceCode\SomeTeamProject\SomeFolder).
That's all. It's a very straightforward concept.
You can maintain multiple workspaces for purposes of isolation, or just have one workspace mapped to the team project collection root ($/), which means that every team project in the collection will be mapped in the same workspace. It's entirely up to you. The advantage of multiple workspaces is that you can explicitly avoid doing things like modifying a bunch of stuff across branch or team project boundaries inadvertently. If you have a workspace for a development branch, you'll only be able to check in a set of files in that branch. If you want to check in files in another branch, you'll have to switch workspaces. It can be a nice sanity check, but it's by no means a necessity.
Workspaces can consist of multiple mappings (for example, $/Foo/Bar -> C:\Foo\Bar, $/Foo/Baz -> C:\Foo\Baz would map those two folders, but ignore any other folders under $/Foo).
Workspaces can also contain cloakings -- explicitly excluding a folder from being mapped. So you could map $/Foo/ and cloak /$Foo/Bar if you wanted everything under $/Foo except the Bar folder.
Workspaces come in two flavors: Server and Local.
Server workspaces were the default from TFS 2005 up until TFS 2012. In a server workspace, every activity you take in source control has to happen through Visual Studio (or an equivalent IDE) -- starting work on a file contacts the server and checks the file out. Files are stored in the file system as read-only unless they're checked out.
Server workspaces are, generally speaking, awful. I do not recommend using them except for in a few very specific cases.
Local workspaces were introduced in TFS 2012 and were first supported (not surprisingly) in Visual Studio 2012. Local workspaces are slightly more Git-like in that editing files does not require an explicit check-out on the server -- you can edit a file at any time in any IDE. This allows you to work offline in a very limited fashion.
This question is asking, "Am I doing something wrong," or "Is this a failure in VS2010 and TFS?"
Whenever I open Visual Studio 2010, I habitually do a "GetLatest" from TFS, and often have it overwrite my local files whether they are updated or not just to be safe. I want to make sure that any code I publish has the latest updates from other team members. Then we all check in our changes as soon as possible in order to stay in sync, as the entire team uses this practice.
What we are finding is that when NEW code is checked in (e.g. a new aspx with code-behind) doing a GetLatest will NOT grab the new files. All we get are updates to files that already exist in our local working directory. Are we doing something wrong? Is there a checkbox we need to tick somewhere to force VS 2010 to get files that are new rather than just update existing changes?
This is quite common and is the result of your local workspace getting out of sync. If it happens a lot you should delete the local TFS cache. That's in %profile%\local\Microsoft\teamfoundation*.
The best way to completely eradicate the issue is to upgrade to a newer version. This was resolved with Local Workspaces in 2012 and with Git in 2013. Its pretty strate forward to upgrade.
I'm using both TFS 2008 and 2010, and I thought that when you check in a file that is unchanged, TFS should automatically determine that there were no changes, and undo the change instead of creating a new changeset for it.
To test this, I am simply checking out any single file in my solution (e.g. web.config). I then (without making any changes) check it back in immediately. I view the history of the file and see there's a new changeset for it. When I compare that file to the previous version, it says "The files are identical".
I thought it wasn't supposed to create a new changeset since the file wasn't changed. I thought this is the way it is supposed to work, and I also thought this is the way it used to work for me. Am I mistaken? Does anyone have an ideas on how I can fix this?
It will if you are using local workspaces but not for server workspaces. Local workspaces were introduced in TFS 2012 with VS 2012 and are not comparable with previous versions.
I have note used 2010 let alone 2008 in a few years, however if I remember correctly you are explicitly saying that you want to check out the entire solution and then check in. In a server workspce, to improve performance on potentially large codebases it does not do those checks.
I have determined what was causing my issue. My organization recently enabled the Local Security Policy setting "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" on all computers. Apparently, VS/TFS 2008 and 2010 don't exactly handle this setting too well, and the check in/comparison of files was one place where it caused a conflict.
By design, VS 2008 and VS 2010 should only commit files that have indeed changed. If a file is pending but has not been actually modified, it should undo the checkout when you tell it to check the file in. But, when the FIPS setting is enabled, it seems to commit the file no matter what.
To resolve the issue, you need to disable the FIPS setting and also restart Visual Studio.
We recently migrated to TFS 2010, and have created a new Team Project. (The old one was created in 2005, and seems to be missing key metadata to allow full functionality in 2010). We've copied all our source, and have figured out how to copy our work items to the new team project, but we can't figure out how to migrate our build definitions.
Is there a way to do this, or will we have to re-create them manually?
Thanks!
[EDIT]
Jeff-thank you for the reply! After reading it, and more deeply considering my situation, I realize that my description (and probably my entire question) was flawed.
We originally upgraded our 2008 team project to 2010. It had previously been upgraded from 2005. Up to this point, we've been using CruiseControl.Net to manage our builds. One of our team noticed that our upgraded project was missing some key metadata, and theorized that stuff had not been added in the migration process, so he created a new 2010 team project and imported our source as a test. Now we have two 2010 team projects: the originally migrated one (that we're all using), and the "from-scratch" one.
In the meantime, I was experimenting with TFS Build on the originally migrated project. I created a dozen or so builds, and was refining them, but we haven't moved off of CC.Net yet.
The decision was made to start using the "from-scratch" project, so I was hoping to somehow copy the builds from one project to the other. I don't see a way to do that... there is no build proj file to copy (TFS seems to keep the build definitions internal in 2010).
Normally, when you upgrade to TFS 2010, any build definitions you previously had will be automatically upgraded with the associated Team Project. It sounds like, at least in your case, that your Team Project did not upgrade completely/correctly so you had to start over with a new Team Project.
To copy your build definition, you will need to:
Copy the TFSBuild.proj file(s) from your old Team Project to the new Team Project - under whatever version control folder makes sense.
Create a new TFS 2010 build and select the Upgrade Template (in the Process tab).
Set the Configuration Folder Path property to the location of the copied TFSBuild.proj file copied in step 1 above.
Fill in the remaining required settings.
Hope this helps.
There's been significant changes to how builds are done from TFS 2008 to TFS 2010. One of the reason's why it appears that 'stuff has not been added to the migration process' is because it just does not exist. Even upgrading from TFS 2005 to TFS 2008 had a bit desired in it's completeness.
Jeff provided some good guidance to use the Upgrade Template, this will actually call the tfsbuild.proj file that was carried over from TFS 2008.
As a good practice, you'll want to create a copy of the DefaultTemplate when a new build definition is created for a corresponding relationship. Do this while creating the build definition in the process part of setup. There is a detail expansion arrow that will allow you to create a new, which is a copy of the default, and name it whatever you like. Unless of course there will be absolutely no customization done to the build definition or all of the builds in that project will be following exactly the same steps. i.e.: dev_sso_ci (build definition) corresponds to dev_sso_ci.xaml in the BuildProcessTemplates folder.
Hope this helps too.
Greetings all,
I have posted this on the MSDN managed news groups as well as a BizTalk site, but I am not sure they get enough traffic that as I don't seem to be getting a response.
Help me StackOverflow, your my only hope.
I am in the process of upgrading our Visual Studio BizTalk projects from BizTalk 2006 R2 to BizTalk 2009.
I start VS 2008 SP1, load up the VS 2005 solution with all our VS 2005 artifacts in it, and the Visual Studio Conversion Wizard starts. All good to here.
The wizard properly reports that the projects which will be updated. These look good. I press Finish and the conversion tool goes and does its conversion thing. The wizard reports that all projects have been converted successfully, However when I view the conversion log, it says that none of the BizTalk projects were converted. If I expand the node on of the non-converted projects, there is no error information as to why it didn't convert.
The two biztalk projects in the solution (the others are c# projects) are both greyed out and VS.Net 2008 says they are unavailable.
If I then right click on the project and select "Reload" the conversion wizard comes up again, this time it asks to create a backup before converting. I select yes to the default location and hit Next. It tells me it's ready to convert, when I hit Finish I get the nice little dialog window:
The operation could not be completed. Unspecified error.
If I look at the conversion log this time, I see the error: Conversion Issues - your.project\your.project.btproj: Error converting project file. Child element <BIZTALK> of element <VisualStudioProject> is not valid.
There are a couple of posts on the net about this issue but no concrete resolutions:
http://dennismulder.net/cs/blogs/dennism/archive/2009/04/25/trouble-migrating-from-biztalk-2006-r2-to-2009.aspx#comments
http://msdn.microsoft.com/en-us/library/dd257156.aspx
The msdn article mentions the project needing a solution file, so I can't see how that applies as the project is already part of an existing VS 2005 solution.
Does anyone have some ideas/thoughts on this? If I have to, I can resort to just creating new BizTalk projects and re-adding the BizTalk artifacts to them, but we have a number of solutions which will need to be converted and if there is a simple fix to get the conversion wizard to work, I would rather go down that route.
Thanks in advance all.
cmb..
** Update - 20090806 **
After some cutting and pasting of .btproj files I have determined the upgrade wizard does not like the fact that I renamed my project build name from Development to Debug
Greetings,
Ok, I openned an incident with Microsoft about this.
Basically the issue in my case came down to the fact that I renamed the build configurations from Development and Deployment to Debug and Release (to match what every other Visual Studio project calls their build configurations). Apparently, the upgrade wizard for BizTalk, doesn't like this very much.
Anyways, Below is the summary email I received from the support engineer at Microsoft about what the problem is and how to fix it. It comes down to hand tinkering with the .sln and .btproj files. Alas..
The default configuration names
(Development and Deployment) for
BizTalk project should not be
modified. Up to BizTalk 2006 R2 it was
not a “true” integration of BizTalk
project systems with the visual studio
in many ways. For that matter, from
supportability point of view, changing
the default configurations is not
recommended. However, you can add your
own configurations without altering
the default configurations. Also it is
not supported modifying the BizTalk
Project template files for Visual
Studio.
In your case, you have re-named the
default configuration names to some
other values. Because of this change
entries for those configuration were
not appearing in the metadata under
various VS files. I tried playing
around with those setting and
eventually with following steps got
the project upgrade working for the
sample project that you provided.
For solution file under GlobalSection(SolutionConfigurationPlatforms)
= preSolution section I did not see entry for default Development
configuration. Added following entry
there Development|.NET =
Development|.NET (here we need default
entries for deployment and
development)
For solution file under GlobalSection(ProjectConfigurationPlatforms)
= postSolution I did not see entry for default Development configuration.
Added following entries there
{3B54116C-9D09-4DAF-9AFD-62EDA64AC12A}.Development|.NET.ActiveCfg
= Development|.NET {3B54116C-9D09-4DAF-9AFD-62EDA64AC12A}.Development|.NET.Build.0
= Development|.NET (here we need default entries for deployment and
development)
For project file under section did not see section
for default Development configuration
Added following entry there (here we need default entries for deployment and
development)
Delete user options file (as it is not needed for the upgrade process –
VS will create the one when you open
the project)
Opened the project on BizTalk 2009 VS 2008 box. Upgrade process is
successful.
The GUIDs are specific to BizTalk
project files. If there are multiple
BizTalk project as a part of the
solution, you have to add the entries
for default configuration for each and
every project in the solution.
can you confirm whether or not you have checked the readonly attributes on all files in the project.
i had the same problem because it was trying to convert a file that was under source control, exactly as laid out in that one link u provided.
after removing the source control bindings i ran the conversion again and it worked
Found this issue when I searched for the current problem I have with BTS09/VS2008 which is I can't add BizTalk projects to a solution, what is going on anybody know about this one
I have been wittering on about the conversion problem since the launch of BTS09/VS2008 nobody seems to have taken me seriously I believe Dennis Mulder was going to raise the issue with Microsoft but haven't heard anything back. As you have found the Microsoft response is just not worth bothering about, if you are converting from BTS06 to 09 then it's a fair chance you will have a sln file, also removing the source control elements didn't work for me either, I actually opened a solution in vs2005 removed all the source control elements and save the solution, then did a conversion to vs2008 didn't work. One very interesting point one of the solutions I tried converting, some of the BizTalk projects did get converted some didn't, spent hours trying to see where the differences once again to no avail. You obviously can create new solutions/projects and add the in the relevant artefacts to these projects BUT WHY should we need to do this, this to me could be a potential showstopper in organisations that have many or large solutions to convert.
Microsoft needs to take this problem seriously and come up with a solution.
My take on this is that it really highlights how many people have moved to BTS09 NOT A LOT if so then I am sure there would have been a resolve to this by now.
Jim,
There are few things. From Dennis Mulder blog post and comments, it looks like Dennis problem is sorted by removing the source control bindings. He is not going to raise a support ticket with MS, he suggested you to open one if required.
In the MSDN page http://msdn.microsoft.com/en-us/library/dd257156(BTS.10).aspx it clearly states the supported migration path is only from BizTalk 2006 R2 to 2009. There is no support from BizTalk 2006 to 2009.
To address your very first line "I can't add BizTalk projects to a solution", Are you able to create new simple BizTalk projects in VS 2008 without any issues?The reason I'm asking this is, there is a chance you might have installed BizTalk and VS in wrong order. It may be worth reinstalling just the developer components of BizTalk Server.
This problem exists in 2010 also when migrating 2006R2 solutions to BizTalk 2010.
I have found a method that works with the least amount of effort possible. It does not require two environments (old and new) but does require the original, unconverted solution-files to work.
http://justbizzie.blogspot.com/2010/10/migrating-biztalk-2006r2-sources-to.html
Let me know if this is also good when migrating to 2009. I expect it to be :)