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.
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 am trying to set up a Visual Studio 2015 solution in the way that StyleCop checks for the C# style and once committed to the source control other developers don't need to do anything else to follow the same style rules and get the same errors/warnings from StyleCop automatically.
As the StyleCop documentation page and GitHub StyleCop describe (both actually say the same) under the title Team Development:
copy all of the files from {Program Files}\MSBuild\StyleCop into a custom folder
in my case under C:\Program Files (x86)\MSBuild\StyleCop\v4.7 there is just one file: StyleCop.Targets
Searching for any StyleCop.dll drives me to another folder (C:\Program Files (x86)\StyleCop 4.7) with many subfolders, dll's, xml, exe, lex...
Now my questions:
Which are exactly the needed files to be uploaded into the project and hence to the source control?
Which are the changes to be done in the configuration project?
Note:
Until now I see the contextual StyleCop menus that allow me to make code analysis and checks.
To use the install, you would need to have each developer install the StyleCop program on their machines, (and on any build server).
There is an easier way... instead use the StyleCop.MSBuild nuget package for each project:
This adds a StyleCop directive to each csproj, pointing at the instance within the packages folder, this means that it is transferable to each dev machine, and any build servers without them needing to do anything.
Then once there is no errors in a project, use StyleCop.Error.MSBuild to keep it that way, again from nuget:
This adds <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> to the csproj, but again keeps it within nuget which I personally find an easier way to track things.
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
Having a bit of an issue here. I'm creating an application in Visual Studio 2010 in C# (Windows Forms).
The UI is going to be done in a WebBrowser (so I can use jQuery goodness and for ease of development).
For this I want to create a folder called HTML which will store all my HTML files and my javascript files.
My colleague tells me to create the folder separately and copy and paste into the compiled application directory referencing the files using: System.AppDomain.CurrentDomain.BaseDirectory.ToString() + "HTML\\FirstPage.htm" etc...
This seems strange to me. His argument is sound - if you need to edit/change anything then you don't need to open your VM (we're on Macs) open Visual Studio, edit, recompile, redistribute etc you just open the HTML files in the application directory. (my argument to this was that its just not that much extra work!)
I can see problems coming when different versions of the HTML files start getting mixed up and such, and to me it feels more "right" to compile the files directly as resources - OR... at least have them as files within the project explorer in Visual Studio.
So my question is: What would be the best way to do this? Would it be best to compile the HTML files as resources (and how would I do that? I'm very new to all this)? Or would it be better to do it the way my colleague said? If so is there a way to get Visual Studio to automatically copy the latest version of the files into the application directory at build time?
Thanks a lot.
No need for resources, they are far less manageable.
Easiest solution will be to add the folder with all the files to the project, and then, in their properties set:
Build Action = Content
Copy to Output Directory = Copy if newer
That's it!
Now whenever you compile your project, all these files would be updated with the latest version.
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.