In other languages such as objective c there are certain files that you can't (or shouldn't) put under version control such as the story board and user data.
Does C# and Visual Studio suffer with any of these limitations?
edit: We are using Smart SVN.
edit2: from your comments it sounds like these would be the optimal global ignores: *.suo *.user *.ncb *.aps bin obj Debug Release temp debug release
If you use a MS-SCCI Subversion plug-in like Agent SVN then the Visual Studio IDE itself will control what files get added to the repository.
At our company we're working with VS2010 and Subversion too. So far we never had any problems. We're using AnkhSVN and TortoiseSVN as clients.
We only added some files to the ignore list, mainly *.user and *.suo. Those files save local paths which are only interesting for local users. No need to have them in the repository. It's no problem if you commit them, it's just not necessary (at least from my personal experience, it might save some trouble not adding them to version control).
Edit to your edit: Yes, those files/folders can be ignored. Basically anything that is created at the client side when it is needed. Also this way users can have their own settings and work environment without colliding with other users path layout, for example.
We have been using visual studio in combination with Visual SVN (commercial use) for over a year now and the only issue we had was that some files from the project templates had multiple line endings which caused the commit to fail. Only after we fixed the line endings we could commit those files.
Another limitation in the current version we use is that committing a solution with externals in it does not go as smooth as it should. Externals not being committed and/or marked as no changes (while they in fact where changed).
A workaround is using TortoiseSVN which is being used in Windows explorer and not in Visual Studio itself. Never had any problems using this program
Related
I find myself loading old C# solutions from VS2010 which have been upgraded to 2017. Thee appear to be a lot of baggage of folders and files coming along.
Is there a way to clean a solution that removes any unneeded files from old versions and only keeps what is being currently used? There may be old files that aren't even referenced any more in the solutions, but how do I know what is what?.
Basically when you attempt a conversion, generally Visual Studio creates a Backup directory to prevent the unintentional situations, as converted solutions or projects might be no longer compatible with Visual Studio versions that are earlier than current version of Visual Studio.
In Backup Folder, There should be an old version of your project.
If it works fine without original version of your project, you may delete whole "Backup" directory as you don't need them anymore.
If any project cannot be converted, it is unloaded and marked as unavailable in Solution Explorer. In this situation, address the problems indicated in the upgrade report as you try to reload the projects that are marked (unavailable), in this case, you may recover from your original project by open a project / solution file located in Backup folder.
Good luck with your project!
The way to clean is good old elbow grease so to speak. Simply remove a file from the project, or comment out a section of a file you think is not being used any more, rebuild. Put it back if build breaks or refactor it out rinse and repeat.
Of course with code files you can use Visual Studio's built in Find References to help as well.
A tool called Resharper can be used to deep cleaner faster, such as changing namespaces, renaming and finding all implementations but Visual Studio 2017 has all the renaming and reference finding you probably need.
Of course have all the code in source control, and incrementally commit every so often so you can revert a build you might break while removing files and not remember exactly everything you removed.
I made the mistake of changing a subroutine in a project and publishing it. Now I want to revert back to the older subroutine. Is it possible to find the older project and retrieve the older subroutine?
Team Foundation Server can do this for you. You can now be set up without any hassle on your developement machine. The integration in the VS Team Explorer is seamless. Very easy to handle. See this guide for working with source control projects
https://msdn.microsoft.com/en-us/library/ms181384.aspx
Even easier and not so much overhead on your machine: sign up for Visual Studio Online (free for a 5 user team). The cloud source control is set up in minutes. If you are not against saving your data in the cloud give it a try.
https://www.visualstudio.com/en-us/products/what-is-visual-studio-online-vs.aspx
The alternatives (SVN, GIT) are also very good (consider reading about the difference of central and decentral source control) but need a little more knowledge and a good workflow.
If you happen to have lost changes before installing version control there's nothing you can do in visual studio. You can try a restore on file level (the option would be previous versions in the windows explorer)
as source code is plain text. There`s a "previous version" mechanism of windows explorer! Just go to the properties of your project folder
Note: previous version / shadow copying must have been enabled before or else the tab will be blank.
No, it is not possible unless you have stored your code in source control. It sounds like you have not yet done this, so I suggest using this is a (harsh) lesson and make the next move the one to install some kind of SCM.
You can signup for a free version of TFS online from microsoft the will integrate directly into Visual Studio. That will allow you to instantly check in changes and view the history of files and in this case, get a previous version of a file.
https://www.visualstudio.com/en-us/products/what-is-visual-studio-online-vs.aspx
I would like to make a backup copy of my Visual Studio 2013 MVC application which is only the source code. Such that I could open the solution on a new machine and have it compile after NuGet has downloaded the necessary packages and so on.
I realise that if the project was in TFS or similair I could go to the new machine and download it like that, however I am looking for a file copy solution.
Now while I could ZIP up the entire folder including binaries that seems like a sledge hammer approach. Having looked around there does not appear to be an easy way to do this. Has anyone got a solution or a utility I may have missed?
Use a version control system such as TFS, Subversion, PlasticSCM, git whatever. Seriously. Distributed VCSs like git or Mercurial will let you transport the whole repository easily.
If you insist on a pack&go approach, the ZIP tool of your choice will, most likely, support include / exclude rules based on file name patterns. For example, in Total Commander it's easy to exclude bin and obj folders.
I am not sure how this feature is called in English but there is something like Clean solution in Visual Studio. This will delete all the binaries and stuff that can be generated. I am not sure it will also delete NuGet downloads but you may give it a try. Afterwards, you can simply copy the project or solution folder.
I have a C# project in MS Visual Studio 2008 that I would like to share on Google Code...I am not sure exactly which files I should be sharing on Google Code if I want to involve other contributors? What I am exactly unsure about is whether to share the entire solution folder or just the .cs files? And if it's the latter how does a contributor go about building the solution and the directory structure?
Thanks
Generally I would include the project file(s) and solution file(s) as part of the source code in a team environment (such as at work), especially if they contain anything that's needed for the proper building of the code (build events, DLL references, etc.). The user file(s) and suo file(s) and stuff like that aren't needed, those are user-specific. But this is in an environment where it can be safely assumed that everybody is using Visual Studio, even the same version.
The code itself doesn't need the project/solution files to be built, and the less you can depend on them the more open-source-friendly the project really is. If the code can be properly built from the command line, or with a tool such as NAnt, then an open source project may be better off with that. So, just from a separation of concerns perspective, try to keep the dependency on the project file(s) as light or non-existent as possible.
Overall, including the project file(s) and solution file(s) is fine if your intended audience is expected to be using Visual Studio.
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)