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.
Related
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'm trying out Visual Studio 14 CTP 2 and noticed there's this .sln.ide folder:
There have been a few questions going around about the .sln.ide (see this, this and this), but two of them are about a file (not folder) with that extension in Visual Studio 2012 (not 2014), and the remaining question is unanswered.
From the hints I've seen in those questions, it appears that the folder is created by the Roslyn compiler for caching purposes. However, I've been unable to find a source that explains exactly what it does.
So what is the purpose of that folder, and how is it used?
It
...is used by Roslyn Compiler engine to store temporary files.
See: http://blogs.msdn.com/b/webdev/archive/2014/06/03/announcing-web-features-in-visual-studio-14-ctp.aspx
As my inspect, Visual Studio 2015 RTM never use this folder again, you can delete it. If you had used .tfignore/.gitignore to ignore .sln.ide, you can delete it too. Cause it won't be generated anymore.
It now uses hidden .vs folder, with the same files in .vs\(solution name)\v14\vbcs.cache. Some of them have .vs\(solution name)\vbcs.cache, I believe it has been used in some preview versions of VS 2015, already been replaced by v14\vbcs.cache and can be deleted too. And also you can delete (solution name).v14.suo because it's been replaced by .vs\(solution name)\v14\.suo.
Visual Studio autogenerates this file. Searching for info on it tells me to never edit this file. Fine, but do I need to store it in my VCS or can VS auto-regenerate it whenever needed?
I believe that Settings.Designer.cs and other similar files should be under version control.
I ran into problems using the advice of the other answer here on this question.
Settings.Designer.cs is only modified if changes are made to Settings.settings, and it is auto generated by Visual studio, but not by build tools.
When I removed Settings.Designer.cs I ran into issues where Visual Studio wasn't auto-generating the file when expected, and I had to do several rebuilds/reloads of my project until finally it randomly appeared, and I'm not sure what actually triggered it.
Also I was having issues on our TeamCity build server because the build tools there were not generating the file, so I had build failures saying it was unable to find Settings.Designer.cs
I found a good rule of thumb in this answer on another question, that basically if the build system modifies the file, then don't put it in source control, but if it is only modified when you make changes to another file and is generated by visual studio, then it probably should be in version control.
Also, Visual Studio 2017 can automatically create a Git repo with a .gitignore file when creating a new project, and by default all of the *.Designer.cs files are included in the Git repo.
The problem with adding these items to version control is, that different version of visual-studio, or perhaps other environments may generate these files in different ways. This sometimes leads to irritating conflicting errors on build servers ect.
VS can auto generate this file.
After reading this answer, I went ahead and deleted the Properties/Settings.Designer.cs but got an error when building the project that "the file was missing". My project still had the references to it. So it is important that you also remove the references from the Project.
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
I currently have one solution that references ten .dll files. Those .dll files in turn all reference a shared .dll file.
Today I started getting an error while debugging that stated, "The source file is different from when the module was built error.", immediately following a recompile of the shared .dll.
I tried all of the usual. I deleted bin and object folders. I recompiled. I closed all instances of Visual Studio and restarted after they were all closed. I restarted my machine. Nothing fixed seemed to fix it.
I'm guessing one of your 10 DLLs references a different copy of the shared DLL, and not the one you compiled.
Since you have all the sources, put all the projects in the same solution, and have the DLLs reference the shared DLL's project. This will solve your problem.
It has happened to me too. Once I fixed it by recompiling project-by-project from ground up (in the same order that VS does).
Another time this didn't help. I can't remember what I did then.
I believe it is a bug in VS.
I notice you are running VS2008. The problem might go away with an upgrade (the supposed bug might have been fixed). VS2010 is also nicer to work with than VS2008 so it could be areason of its own to stay current. Why not download an evaluation VS11 and try it there.
Move all projects to one solution, reference them in a simple and correct way. Compile. Now you have the right DLLs everywhere and can go back to your more diverse solution(s).
You can also try to use MSBuild. It is easy since you already have the projects in VS. Once it is build by MSBuild (which VS uses itself) it should probably compile in VS again.
Finally you can try to build with nAnt. Once it compiles you can probably compile in VS again.
Good luck. I've been there. It sucks.
I suppose you referencing in your project directly to some DLL, and not a project. Which means if you even cleanup and rebuild, the same dll will be used like a reference.
Very often this is a problem, so I suggesting you check your references.
[edit] Assumed this was asp.net, disregard. [/edit]
Have you deleted everything your temporary .NET folders?
Either in:
C:\Windows\Microsoft.NET\Framework[Your Version]\Temporary ASP.NET Files
or
C:\Windows\Microsoft.NET\Framework64[Your Version]\Temporary ASP.NET Files
When comparing last-modified dates of the shared .dll across output folders of all of the solutions with the file that was stored in the output folder of the primary solution, I noticed that they were not the same as the file that I had just built.
This didn't make sense to me, so I simply copied the new files into the output folder. This did NOT solve the problem. On subsequent builds, the old version was again placed into the output folder, immediately causing the error while debugging...
During compilation, an older version was being pulled along with one of the other referenced .dlls. There is obviously some sort of check that is made with the names of files pulled in so that only 1 file is used, but no check is made for latest version number.
I was able to actually solve the problem by creating a reference to the shared .dll from the primary solution. Direct references are obviously (or perhaps hopefully) pulled in before files that are referenced by references (and are already copied into the same output folder as those referenced .dlls), so the latest file was successfully pulled in first.
If clarity is needed, let me know!
I rarely respond to posts since I am generally too busy, but I just spent a ton of time on this same exact problem. I am running VS 2008 in Windows 7. I had set the my Visual Studio to run in XP Compatibility Mode to fix some issues I had with a different project and forgot to reset it to NOT run in compatibility mode.
Once I removed the Run In compatibility MODE (In Windows Explorer on the DevEnv.exe) my problem with the source being out of sync with the debug information went away.
Hopefully this might help someone in the future with the same problem.