A bit of Background:
I've migrated 3 old projects on a Win2003server to a Win2008R2 server (saying goodbye to IIS 6, VS2008, and Visual SourceSafe!). This Visual Studio 2012 solution with the 3 projects compiles and runs OK but I need to make some minor changes. Before I do much more, I am trying to add these projects to "source control" (TFS 14.0 with a local workspace). Two projects were added without problems. The 3rd project won't allow some items to be added to the team project folder and gives this message:
TF10122: The path ‘$/MDW/MortgageDataWeb/MDS/$Common/$BuildNaviagator.asp’ contains a ‘$’ at the beginning of a path component. Remove the ‘$’ and try again.”
The local path of this old classic ASP project is D:\Projects\MortgageDataWeb\MDS and one of the subfolders is named $Common and within that are dozens of files beginning with a $ in the filename and the filetype is .asp.
I've done lots of research on this error message and I am deducing that the filenames and folder names in this project cannot begin with (nor contain??) any dollar signs. Most every explanation points at something about "Build Definitions" and Workflow 4.0 issues which I don't really understand.
The code was written about 9 years ago and I would be very reluctant to attempt global source code changes to hack out the offending $ from the item names.
Is there anything simple I could do to get this project added to TFS so I can move forward with my minor changes and be able to track things with TF version control? I'm not ready to need full-blown ALCM features (just want to view pending changes, check in, compare differences, etc.).
Edit:
Regarding versions of TFS, I followed advice from here:
https://msdn.microsoft.com/en-us/library/ms181475.aspx
Included there is a question about how to find version:
A: From a web browser and for an on-premises TFS, enter the following address: http://ServerName:8080/tfs/_home/About.
For Visual Studio Online, enter the following address: http://AccountName.visualstudio.com/_home/About.
So, I did this on my development server and got this which looks like 14 to me:
The message in the exception is correct. Per Naming Syntax, Conventions, and Limitations:
Most names in Team Foundation version control cannot begin or end with spaces or tabs. Any character can be used for names or labels, except
...
A dollar sign ($) cannot be the first character in a file name.
There is not a workaround. You cannot place files with those names in TFVC.
Related
InstallShield must be the crappiest "industry standard" application in existence, for reasons too numerous to enumerate here. However, one of those deficiencies is something I'd like to be able to fix, and with my first foray into writing an extension for Visual Studio (currently using 2015 version).
InstallShield has created a .isproj type, to allow integration with Visual Studio. This allows a developer to create an installer that references the output of a project as the files to include in the installer (rather than having to manually select individual files to include). This works well enough as long as the .isproj is being built in Visual Studio, and in a solution that references the project for which you need the output.
However, I also have an automated build for my installer projects, that we run on a build server using MSBuild. When attempting to build this way, we were getting completely opaque error messages indicating that the project output references above couldn't be resolved.
As with all InstallShield errors, Googling for answers turned up nothing except for multitudes of other people having the same problem. So I decided to dig into the plain text of the .isproj to see what I could find.
As it turns out, the .isproj type is a just a regular MSBuild script, and it even has lines commented out that explain options that can be added to the project; one of those things that can be added is an ItemGroup containing ProjectReference nodes. Manually adding the nodes helped solve the problem. Command-line build now works.
However, I am dissatisfied with a) having to manually type this stuff in, b) having no visual representation of what projects are being referenced, and c) not finding out about a problem until the build fails. So, I would like to be able to extend Visual Studio to help me with this. Here's what I'd like to do:
1) Add a "References" node to the project in Solution Explorer that acts like the References node for any normal .csproj.
2) Restrict the available References to other projects in the the current solution.
3) Visually represent a project with missing references (e.g. by underlining the project name with a colored squiggly, as with errors/warnings), and potentially failing the build if missing (depending on whether I want to treat it as an error or a warning; TBD).
To these ends, I've downloaded MPF for Projects - Visual Studio 2013, which provides an SDK for creating a new project type.
However, before digging too deeply, I need to know if it's even possible to EXTEND an existing project type, as described above, as I obviously don't have InstallShield source code. Also, any links or guidance as to a starting point for doing so would be greatly appreciated.
I have just started having this issue today with VS2012 and TFS.
We have our VB6 classes stored in Team Foundation Server.
I checked out a (VB6 *.cls) class for edit (in VS2012 TFS), then edited it in the Visual Basic 6 IDE, changing no more than 20 lines out of about 8900 lines in the class, before saving the class.
Unfortunately, when I try to compare my changes with the Latest version in TFS, I am getting hundreds of changes because either Visual Studio or TFS is changing all the Adodb. to 'ADODB.' as in the below picture
This makes it very difficult for my colleagues to review my code changes, as there should be no more than about 20....
EDIT: It looks like it is VB6 doing all these changes...
What do I need to change to fix this?
This is not a TFS issue. VB6 does this when it thinks the declaration of an object or variable has changed it's case-spelling.
But you can address this in TFS. Configure TFS to use an external compare tool, such as Beyond Compare or WinMerge (there are lots of others) that support case insensitive comparisons.
I have a solution with many projects. This is actually a solution that contains a mix of class libraries and various web applications. It seems that if my colleague makes a change to one of the web projects (or if I do) and then check it in. And then when either one of us gets the latest version project references become broken. They still appear in the references section with no indication of an error, but when you try to compile it cannot see the libraries.
To solve this I have to remove the references and add them back in. Any ideas on what may cause this problem?
Make sure that the paths are relocatable, that you both have the same paths on your PCs (i.e. that you have not used TFS workspace mappings to put different folders in different places), and that you don't move projects around or rename folders etc.
Even when everything is clean and tidy, Visual Studio will occasionally decide it can't find a file that's right under its nose, or that a file somewhere else on your system looks prettier, and it will break the reference. You just have to delete and recreate it in this case. But this usually happens once a month in a team of 10-20 people, and should not occur every time you check in.
After a lot of editing of my build templates (I recreated them in 2012 to avoid any issues.. but then I suppose I got sloppy and simply copy/pasted whole blocks from the old workflow, and I suppose that must have completely destroyed my versioning) I now have problems with just one build definition based on the build template I edited. (All other ones seem to be working fine.. so I suppose that one got a problem during all the editing. (I was mostly adding and removing Version=11.0.0.0 to the assemblies in the build template))
The exact error is:
Parameter Items to Build: cannot convert value
'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' of
type Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings
to type
Microsoft.TeamFoundation.Build.Workflow.Activities.Buildsettings,
reset to default.
It is displayed when editing the build definition and wanting to select the project/solution and configuration to build. Actually, with this now I cannot save (without error) any more and the value gets deleted again.
(I am using VS 2012 (VS 2010 still installed) against TFS 2012.)
How to fix?
Open up your XAML and look at the xmlns's on the Activity root node:
Here's a snipped version of mine:
<Activity mc:Ignorable="sads sap sap2010" <!--Removed-->
xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:mt="clr-namespace:Microsoft.TeamFoundation;assembly=Microsoft.TeamFoundation.Common"
xmlns:mtbc="clr-namespace:Microsoft.TeamFoundation.Build.Client;assembly=Microsoft.TeamFoundation.Build.Client"
xmlns:mtbw="clr-namespace:Microsoft.TeamFoundation.Build.Workflow;assembly=Microsoft.TeamFoundation.Build.Workflow"
xmlns:mtbwa="clr-namespace:Microsoft.TeamFoundation.Build.Workflow.Activities;assembly=Microsoft.TeamFoundation.Build.Workflow"
xmlns:mtbwt="clr-namespace:Microsoft.TeamFoundation.Build.Workflow.Tracking;assembly=Microsoft.TeamFoundation.Build.Workflow"
xmlns:mttbb="clr-namespace:Microsoft.TeamFoundation.TestImpact.BuildIntegration.BuildActivities;assembly=Microsoft.TeamFoundation.TestImpact.BuildIntegration"
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
xmlns:mtvc1="clr-namespace:Microsoft.TeamFoundation.VersionControl.Common;assembly=Microsoft.TeamFoundation.VersionControl.Common"
Look for Version Specific references (usually "10.0" or "11.0") and remove them so they look like the ones I have above.
Also, check you project references and ensure that they are not Version Specific.
Here is HOW to change the assemblies in your TFS Template:
In Source Control Explorer, browse to the BuildprocessTemplates and
open (double-click or choose "View" from the Right Click menu) the
template that your build is based on (the one giving you the above
error)
You should see a visual diagram of the workflow. At the bottom are
three tabs: Variables, Arguments, and Imports. Click on Arguments.
Select the BuildSettings Argument
Find the Properties box. The properties for an arguement are:
ArgumentType, Direction,IsRequired, Name, and Value.
Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings
should be the selected Type but the problem is (typical) you can't
tell which version of this assembly is selected. Click the drop
down.
At the bottom of the list choose "Browse for Types..."
NOW you can see all of the available assemblies and their versions. Choose the one you want, most likely upgrade to the latest. Be sure to go through all of the various arguements and make sure their types are all are set to the same version to ensure compatibility.
You may encounter issues now saving the file. All may appear to be ok. TFS indicates it knows the file has changed, checkin seems to go smoothly, but when the file is opened the assemblies still reflect v 10. If you open the same file from the file system you may find that the assemblies in the file really are v 11. What give? No idea. Some sort of glitch in VS.
But here is a work around:
Uninstall VS 2010 Team Foundation Server Power Tools from your
development machine
Open VS 2012 and make sure the template has no pending changes (undo) and get latest version
CHECK OUT FOR EDIT (important) but do not make any changes in VS (it
won't open anyway since the 10 assemblies were uninstalled in a
previous step)
Close VS 2012 (important because if it is open it will appear that your change didn't take)
Open the template from the file system (I used notepad to eliminate any interference from VS) and perform a find/replace on "Version=10.0.0.0" with "Version=11.0.0.0" and save the file
open VS 2012 and now you should be able to see the workflow designer
Of course, check in the file
I would like to change the "Visual Studio 2010" folders location to my Dropbox folder, so it gets synced every time I make a change. I have searched on the internet, but haven't found a solution yet.
Is it possible to change the "Visual Studio 2010" folders location from within Visual Studio 2010, specifically Visual C# Express 2010?
If you want to relocate everything in the Visual Studio 2010 folder, it takes a couple steps:
In Visual Studio, go to Tools > Options > Projects and Settings > General. Set the three locations as desired.
In Registry Editor, navigate to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0. Set the remaining locations that still reference Documents\Visual Studio 2010 as desired.
Tools > Options > Projects and Solutions > General > "Projects location" setting. Change the others too if you routinely create templates.
As stated by the other answers, some of the paths are configurable (settings, default projects location, and the user template locations) and can be set under Tools->Options. However, it is important to note that the actual registry value that determines the root path is at HKCU\Software\Microsoft\VisualStudio\12.0\VisualStudioLocation, and that this value is only taken into account if HKCU\Software\Microsoft\VisualStudio\12.0\MyDocumentsLocation is set correctly.
To change these registry keys properly:
Make sure Visual Studio is not running.
Open the registry editor and first make sure that HKCU\Software\Microsoft\VisualStudio\12.0\MyDocumentsLocation is set to your actual My Documents location (this is very important, otherwise some of the other paths in the registry will take on default values on the next open/close cycle) and does not have a trailing slash. If this registry value is not there, you must add it.
Change the HKCU\Software\Microsoft\VisualStudio\12.0\VisualStudioLocation to whatever path you'd like the files to be stored at.
(Optional, but recommended) Search for more references to the old path in the registry under both 12.0 and 12.0_Config and update them accordingly.
Note that if you ever change the location of My Documents in Windows, several of the paths (including VisualStudioLocation, which most of the others are based on) will revert to their defaults, and you'll have to follow the steps above again.
(Modify the Visual Studio version number as applicable -- 12.0 is for VS2013, 11.0 for VS2012, etc.)
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\NewProjectDialog\MRUSettingsVenusProjectLocationEntries
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\NewProjectDialog\MRUSettingsLocalProjectLocationEntries
if above solution doesnt work try this ones.
From Tools Option> projects and Solution as show down
In case someone come across this question these days, in VS2017 Community there is a "Location" node under Tools-> Options-> Projects and Solutions-> Locations. The fields are no longer under "General".