We Keep Coding

TFS messing with my workflow coding style.

I recently converted from Vault to TFS for C# coding (language probably doesn't matter) in VS2010. My workflow used to be as follows:
If I don't want to check a file out or the file is already checked out by someone else, I simply remove the read-only attribute and start editing. At that point, Vault would stay out of my way. Later on, I would just merge my changes.
With TFS, by default, it wouldn't let me edit the file at all (because it checked out by someone else), even though I removed its read-only attribute. So I went into Tools/Options/Source Control/Environment and checked the Allow checked-in items to be edited.
This setting does allow me to edit the file, however, every time I press Ctrl-S to save it, it complains that the file is locked for check-out.
How can I get TFS to edit my files in peace?

You should have no issues unless the other person who is working on the file is locking it when they check it out.
My settings are as follows and work well for your situation:
Options -> Source Control -> Environment
Team Foundation
[] Get everything when a solution or project is opened
[] Check in everything when closing a solution or project
[] Display silent checkout command in menus
[] Keep items checked out when checking in
Checked-in items
Saving: Check out automatically
Editing: Check out automatically
[] Allow checked-in items to be edited
In the "Team Explorer" window right-click on your {Team Project} -> Team Project Settings -> Source Control
Make sure that "Check-out Settings" has [x] Enable multiple check-out
Also when checking out files make sure "unchanged" is selected such as in this screen shot:
from
http://social.msdn.microsoft.com/Forums/pl-PL/tfsversioncontrol/thread/4353d676-1794-4db0-9d9d-f2a231315980

There is nothing wrong with multiple people checking out the same file at the same time. That is a large part of why source control was created in the first place, so that this could be done. By checking out the file, and not just editing it locally outside of TFS's knowledge, you are also telling others that you are working on the file (useful information to have).
As stated earlier, unless the file(s) are checked out and locked nobody will be prevented from accessing or modifying the file.

There is a setting available for each project that will explicitly disable multiple check-outs if it is not selected.
If you have appropriate permission, in the Team Explorer... right-click on your project and choose "Team Project Settings -> Source Control...". On the "Check-out Settings" tab, there is a checkbox for "Enable multiple check-out". Verify that the option is checked.

If you're used to git (or are willing to give it a try) then I highly recommend git tfs. It gets rid of the whole annoying paradigm of having to clear readonly flags on files, as every file is effectively cloned from the TFS source tree into a git repository. Then when you push your changes back into TFS it marshals the changes back into a format TFS approves of.
For example
git tfs quick-clone http:tfs-server/tfs/yourCollection $/YourCode/YourBranch YourDirectory
checks out all your files from TFS into YourDirectory, you can then modify these files as you would any other files on your computer, then to send them back to tfs you can issue the commands
git commit -a
To check the files into git, then
git tfs ct
To push the files into the TFS repository. More details can be found here: https://github.com/git-tfs/git-tfs

Visual studio - can't remove project configurations

I have a major problem with project configurations. Everything started when I wanted to add new solution configuration (named "Dev_WithSource") based on existing "Debug" configuration and checked "Create project configurations". For some reason project configurations were registered inside sln file, properly showing in Configuration manager, but "PropertyGroup Condition" blocks in csproj files weren't created. That resulted in "OutputPath not set ..." error.
So, I tried to repeat whole procedure. After deleting all lines mentioning "Dev_WithSource" from sln file, "Dev_WithSource" project configurations are still showing in configuration manager. I searched all csproj and sln file in my solution. Neither of them contain text "Dev_WithSource".
After all that I event tried developing add-in. I can fetch phantom configurations with project.ConfigurationManager.ConfigurationRowNames but I also can't delete them.
Am I missing something? Are those configurations stored in some other files and not csproj/sln?
Thanks.

Access the configuration manager in one of two ways:
From the menus on top: Build > Configuration Manager...
From the drop down listing your configurations on the main tool bar select Configuration Manager...
In the configuration manager dialog under Active solution configuration: choose <Edit...> from the drop down.
A dialog opens showing all the configurations for your solution. Here you can select and click the Remove button.

Right-click->Unload your project with the configurations you want to remove.
Right-click->Edit project file xml directly.
Delete the Property groups containing conditions containing the name of the platforms/configurations you wish gone.
Save and load project again. Unwanted configurations should be gone.
If a configuration seems set up right but OutPutPath is still "not set", try moving its propertygroup tag up in the xml.

Let's suppose you want to remove "Release" configuration from the entire solution and the projects. So, first you go to Tools -> Nuget Package Manager -> Package Manager Console.
Copy and past the following command in the console to remove the build from all the projects. You may want to replace "Release" with the configuration name you wish to delete.
Get-Project -All | Foreach { $_.ConfigurationMAnager.DeleteConfigurationRow("Release") }
Finally, remove the configuration solution-wise as explained by Mike Grimm's answer.

I know this is an old thread, but this was the answer for me:
In the Configuration Manager, select "Edit..." in the "Configuration" column for each project (not via the dropdown named Active solution configuration) that has configurations you want to remove.
In the dialog that pops up, mark each unwanted configuration and select "Remove".
Copied from How do I remove a project configuration in Visual Studio 2008?

You need to remove the configuration from the solution AND the project. From the Configuration Manager:
Active solution configuration > Edit > Remove
Project contexts > Configuration > Edit > Remove

I solved this with utility which parses csproj files and inserts necessary propertygroup blocks into csproj files. Old project configurations still appear in configuration manager but I gave up trying to delete them.

In my case the issue was that the solution file was not in the same folder as project file so I had to copy the nuget folder into the solution folder to resolve this issue.

In Visual Studio for MAC -
Double click your Solution > Configurations > General.
Click on your 'ConfigToRemove' in the list then Remove (Ensure you tick delete also Configurations in Solution items), then Yes.
Click OK to save your changes.
Now, right Click on Solution and Tools > Edit File.
Go to "GlobalSection(SolutionConfigurationPlatforms) = preSolution" and remove all the Configurations you no longer need otherwise they will still show up in Configuration Mappings even though there are no mappings in the project!
Save and your done.

I know I am bit Late but here is complete solution.
To remove configuration completely from solution and project property then open .sln file in any IDE as Plain text and delete all information regarding the configuration.
NOTE- don't delete GUID values and debug/release configurations
Then open .vcxproj file in XML format and delete all information regarding the configuration. This includes fundamental property for it, Platform Toolset and Assosiated property elements in XML language.
NOTE- make sure to delete end tags.
when you go back to visual studio, click replace all and you are good to go.

C# - Visual Studio project build

I have the following problem.
I made an application in C# (using Visual Studio 2010). Everything worked fine.
Then I had to make some changes in a "main.cs". Did those... all fine again.
Then I had to make other changes in same file. Did those... cleaned the solution built it. The problem is that when I run/debug/anything the application I get the same result as I did before I made the changes. I even tried to break the code (called a random function that didn't exist, used wrong syntax), but the result was the same "Build successful" and the old version.
Is there some kind of cacheing mechanism or something? How do I get rid of this problem?
I added prints for the "compile" solution... I can't find the build property.

Try deleting the bin and obj directories in the Visual Studio project directory. The obj directory contains the temporary files used to create the binary while the bin directory contains the binaries for that project. In addition, check if there are any warnings being shown when you build your solution.
I was able to reproduce the same error i.e. build successfully even though the file has not been compiled. The Build Action of the file had not been set to Compile.
The correct Build Action for a code file (main.cs) would be Compile.
According the updated question the file properties does not have the compile option
The reason for this is that the file (main.cs) has not been included in the project, but the "Show all files" button is "on" in the Solution Explorer. The file has not been included in the project (hence not compiled) and the file icon is greyed out in Solution Explorer.
To include this file in the project, right click on add existing item to the project (see following image). In the subsequent dialog select the file (main.cs) and click on the add button.
This should solve your problem.
In future, it is best to keep the "Show All Files" button as "off" to avoid confusion.

Is it possible you have selected the build and run last successful version? Check out my answer to something similar here. If the changes you made broke something and you had checked the boxes and hit yes to the dialog boxes in my answer below then that's most likely the issue.
Cannot see changes I make when I run my application in Visual Studio

Make a backup of your solution.
Delete the .cs files from within the solution explorer. If your program compiles and runs, than you are linked to source folders and not actually using the one in your solution.
I doubt this is it, but worth a try. The other things that came to mind you have already eliminated out with the previous answers.

Simplifying setup and deployment in c#

I have made an application, which keeps getting updated frequently. So every time a change occurs, i've to include it's fresh builds to the setup and deployment program again and again. Is there any way to simplify the procedure? The files to be added are static in number and exist in a folder. I've heard we can write installer classes in c#, does my requirement has any thing to do with it?
I think ClickOnce doesn't suit my requirement because, for the first time i want it to run like a setup package, since it has some packages and some settings needed to be implemented on the user's machine at the time of install. Can click once help me with that? Also i want to run my application as an administrator and it references to many external dll files. So will it help my purpose?
I finally did it using clickonce deployment. I used content files to mark all the files i wanted to copy to the target computer and used clickonce deployment. Then i modified the way my program starts, so that i can lauch the installer script i wanted to run only when the app runs for the first time. Further i hosted it on IIS and had to change lot of MIME types and add new ones for the download to work over internet

Look into something called "ClickOnce" deployment. It automates a lot of what you're talking about.
EDIT: You can add custom installer actions to a ClickOnce project just like any other, to set up additional components and whatnot. As for permissions, ClickOnce will let you run as administrator if you so choose, but that sort of thing isn't recommended, and it might whine about it.

You can use ClickOnce (http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx) which simplify the deployment process.
Maybe you can also automate the build process using NANT (http://nant.sourceforge.net/).
HTH

Yes, you can do that.
I assume you want the client to update itself when ever there is a new version.
This needs a few changes in the client code. Essentially how it works is check for availablilty of new version at a predefined location. Update you new versions to this location. On the client side, show a message to the user if he/she wants to upgrade to the new version.
You can find a link to sample project out here and here.

You can add a Setup project in your solution inside Visual Studio and then add your other project(s) outputs, or static files to the Setup project as references. The Setup project will then detect your dependencies automatically and each time you do a Rebuild All (or you rebuild/build your Setup project) it will automatically include all the necessary files.

What type of project is it? In many cases, ClickOnce can do the job for you, at nominal effort.
Beyond that - you can usually hook your installer build into your build process; some tools will do this for you.
Installer classes run at the client - so I don't think they relate to your build process...

I would flag the files as Content in their respective properties and then in the deployment project right click the project, go to File System and then right click the folder, click Add and select Content Files from the dialog box. This should copy the newest files over every time you build the deployment project.

Why is "Set as Startup" option stored in the suo file and not the sln file?

It seems like this setting should be stored in the solution file so it's shared across all users and part of source code control. Since we don't check in the suo file, each user has to set this separately which seems strange.

It is absolutely necessary that everyone can define their StartUp Project themselves, as Jon has already said. But to have a dedicated default one would be great, and as I can tell, it is possible!
If you don’t have a .suo file in your solution directory, Visual Studio picks the first project in your .sln file as the default startup project.
Close your Visual Studio and open the .sln file in your favorite text editor. Starting in line 4, you see all your projects encapsulated in Project – EndProject lines.
Cut and paste the desired default startup project to the top position.
Delete your .suo file.
Open your solution in Visual Studio. Ta daa!

In most cases, it does make sense to have a default on this.
It would be much better to accommodate a default startup project and store this in the .sln file, but which can be overridden by a developer in their .suo file. If the startup setting isn’t found in the .suo file, the default startup project in the .sln would be used.
Actually, this has been suggested on Visual Studio’s UserVoice.

Why should it be a non-user-specific preference?
If I've got a solution with 10 files in, and one developer is primarily testing/using one of those tools, why should that affect what I start up?
I think MS made the right choice on this one. The project I want to start is far from necessarily the project that other developers want to start.

I wrote a little command line utility for Windows called slnStartupProject to set the Startup Project automatically:
slnStartupProject slnFilename projectName
I personally use it to set the startup project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on GitHub. Forks and feedback are welcome.

If you are using GIT, you can commit the default SUO file and then mark it as unchanged using
git update-index --assume-unchanged YourSolution.suo
It works also if you want to have more than one project in your default start group. The only disadvantage that I know about is that this command must be run by everyone who don't want to commit the SUO file.