Visual Studio has a "Refactor Rename" feature where I can right-click any type or member and rename it, and it will update all references within a project or solution to match. Is this functionality accessible from MSBuild command line tools, without having to open Visual Studio?
(I'm doing this because I have a project that is so large that Visual Studio runs out of memory while attempting to calculate where the rename is needed).
As far as I'm aware that's not something that's available outside of Visual Studio; although you probably have a couple of avenues available for getting it done.
The first thing that I'd try is using a lighter editor, VSCode, Atom, etc. Something that uses less memory, but will still hopefully let you get the rename done. You might have to use a regex find/replace to get it done; whether that's an option kind of comes down to if you can make an accurate regex.
If you can actually get the project open in VS with no (or less, at least) problems, then you could also start unloading projects that aren't relevant to the rename. If you know that it's only available in certain projects then unload everything else, perform your rename, and reload the projects. If it's everywhere then you might still be able to do something similar to this, perform the rename in a few projects, unload them, load the next few, rename, etc. Although I'm honestly not 100% sure that'll work, I've never attempted it.
Regardless of what you try, if you haven't already be sure to have your code in source control just in case. I'm sure this is doable, but maybe not via the VS command line.
No. There is no shipping msbuild target, task or tool to rename variables from the command line.
You could of course write yourself. :)
But I highly suggest using Visual Studio Code as an alternative to Visual Studio for loading large numbers of projects. It's an outstanding cross platform IDE. And who knows, perhaps someone wrote a plugin for it to rename variables...??
Related
I have a C# WinForms project, which I am working on in Visual Studio 2017 (although it was originally created in the 2015 version).
I don't recall having done anything special, but it has added a file called .dtbcache, that it wants to add to git. The file has no extension, and a Google search doesn't show any results.
The file is located in ..\repos\myprject\.vs\MyProject\DesignTimeBuild. Which means that the "dtb" part of the file name probably means design time build, but that doesn't really make it that much better.
Can I delete it or add it to .gitignore? I would prefer not to include it in our git repository, unless it is required.
Short answer: You can safely exclude it from your Git repo.
Long answer:
You're right that dtb stands for Design Time Build. This is a file automatically created by VS2017, with a bit more information here and here (links to a blog from someone working on the Visual Studio project system). In summary, it's Visual Studio more or less extrapolating what files will be produced in order to make sure Intellisense is fully available as intended.
From the linked articles, one of the purposes of this is to make sure Visual Studio has an answer in certain cases:
Given an assembly reference in the project file, what assembly on disk is that reference going to actually refer to at compile time?
Given a XAML file, what is the code that is going to be generated by the XAML compiler at compile time going to look like?
Given a glob file pattern (*.cs), what files are actually going to be included at compile time?
So the files, being generated on the fly, are not needed in your Git repo, and can safely be excluded. Moreover, from what I can tell, these files are specifically made and used by Visual Studio 2017.
I'm building a WPF app w/ Visual Studio 2015 (Update 3), and—at least by now, I'm not sure for how long this has been the case—every time I make a change and compile, I'll get a failed build w/ the error
6>CSC : error CS2001: Source file 'C:[...]\Obj\Debug\AnyCPU\GeneratedInternalTypeHelper.g.cs' could not be found.`
If I just build a second time, though, it works just fine.
This smells to me like a dependency on another file that is generated afterwards or something like that, but I haven't been able to find out what it is, a google search didn't net anything either, and neither did a search through my project what this file is used for in the first place (the name suggests its purpose, but I don't know where exactly it is used).
It might also be that the (group-policy-mandated) Anti-Virus is holding an exclusive lock on the file or its dependency for a moment too long, and VS stumbles over that, I think I remember a problem like this at my last job, but I'm not sure that is the case (and I can't simply disable the scanner for a check, it's completely locked down and I don't want to violate company policy for trying to circumvent it).
Any ideas? It's not critical since it's easy to work around, but it's annoying and I don't really want to check in the project like this in the end.
I had the same issue and i found why it happened (in my case).
Every project of our solution has the same output folder.
The file GeneratedInternalTypeHelper.g.cs was generated at the same place for each project.
The build order/dependencies were computed and Visual Studio found that some project could be build in parallel.
In Tools > Options > Project & Solutions > Build and Run you can find the option "Maximum number of parallel project builds.
After changed from 8(in my case) to 1, no more files generated at the same time :)
It is a little slower to compile but really less annoying than compile multiple times... \o/
An alternative solution is to add project dependencies in the solution for the projects you don't want to build in parallel.
With this you can keep the parallel project build for the other projects.
I have just chased down the same error. In my case it was caused by Git checkout inserting a "%20" into the folder name of the solution where a space was expected. Replacing "%20" with space fixed all these missing *.g.cs errors. Thought worth mentioning here.
I have a need to identify if I'm referencing a specific assembly in my project/solution. I've not found an easy way to do this (I want to do it at design time and not run time if possible).
Seems this should be easy, but I'm not finding a way in VS, directly. Ideally, if I could see what/where I'm referencing (assuming that I am) would be great, too, so I can remove such references from my code.
Simply searching for "Assembly." in my code turns up nothing, now, for example.
A concrete example is in order: I want to know if I use anything in System.Reflection.Assembly. And I'd like to find the code that does it (in my source) if I do.
Do you want something like Assembly.GetReferencedAssemblies Method ?
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getreferencedassemblies(v=vs.110).aspx
In Visual Studio (almost all versions) open the Solution Explorer window the second "folder" is the References section. If you expand that you'll be able to see the referenced assemblies.
Image from robowiki
In, Visual Studio 2010, I have a solution with various projects and I have two projects that share a C# namespace with the same name, however, they are intended to be separate namespaces.
I want to rename both namespaces to different ones to prevent confusion. However, I wonder if there is a safer solution other than having to use Ctrl+H and choosing to replace all the occurences in the project.
I know you can just retype the name of a namespace in code and VS will ask to you if you want to rename all occurences, however I don't know if VS will be smart doing this to each project separately, and it says if I rename it I cannot undo the action because it will be applied to too many files. I also tried to open a project alone to prevent this but VS automatically opens the whole solution.
You can use a refactoring tool such as Resharper to do this safely.
There are also other tools available, but I usually use this because it works very well for me.
Copy the folder that contains your solution, and projects, to another folder (just in case)
Create a new solution with just projectOne inside and perform the refactor of that namespace there.
Create another new soution with just projectTwo inside and perform the refactor of that namespace there.
Open the original solution, thas has those two projects inside, and see if the results are what you expected
You can load the projects one at a time and refactor the namespaces as you wish. Open the entire solution and unload one of the two projects.
If you want advanced refactoring, you can try DevExpress' Refactor Pro or ReSharper. Both are awesome refactoring tools.
Our product's solution has more than 100+ projects (500+ksloc of production code). Most of them are C# projects but we also have few using C++/CLI to bridge communication with native code.
Rebuilding the whole solution takes several minutes. That's fine. If I want to rebuilt the solution I expect that it will really take some time. What is not fine is time needed to build solution after full rebuild. Imagine I used full rebuild and now without doing any changes to to the solution I press Build (F6 or Ctrl+Shift+B). Why it takes 35s if there was no change? In output I see that it started "building" of each project - it doesn't perform real build but it does something which consumes significant amount of time.
That 35s delay is pain in the ass. Yes I can improve the time by not using build solution but only build project (Shift+F6). If I run build project on particular test project I'm currently working on it will take "only" 8+s. It requires me to run project build on correct project (the test project to ensure dependent tested code is build as well). At least ReSharper test runner correctly recognizes that only this single project must be build and rerunning test usually contains only 8+s compilation. My current coding Kata is: don't touch Ctrl+Shift+B.
The test project build will take 8s even if I don't do any changes. The reason why it takes 8s is because it also "builds" dependencies = in my case it "builds" more than 20 projects but I made changes only to unit test or single dependency! I don't want it to touch other projects.
Is there a way to simply tell VS to build only projects where some changes were done and projects which are dependent on changed ones (preferably this part as another build option)? I worry you will tell me that it is exactly what VS is doing but in MS way ...
I want to improve my TDD experience and reduce the time of compilation (in TDD the compilation can happen twice per minute).
To make this even more frustrated I'm working in a team where most of developers used to work on Java projects prior to joining this one. So you can imagine how they are pissed off when they must use VS in contrast to full incremental compilation in Java. I don't require incremental compilation of classes. I expect working incremental compilation of solutions. Especially in product like VS 2010 Ultimate which costs several thousands dollars.
I really don't want to get answers like:
Make a separate solution
Unload projects you don't need
etc.
I can read those answers here. Those are not acceptable solutions. We're not paying for VS to do such compromises.
By default Visual Studio will always perform build of every project in your solutuion when you run a single project. Even if that project doesn't depend on every other project in your solution.
Go to Tools | Options | Projects and Solutions | Build and Run and check the box "Only build startup projects and dependencies on Run".
Since now when run your project (F5 key), Visual Studio will only build your startup project and the those projects in your solution that it depends on.
Is there a way to simply tell VS to build only projects where some
changes were done and projects which are dependent on changed ones
(preferably this part as another build option)? I worry you will tell
me that it is exactly what VS is doing but in MS way ...
Not really (you understand it already).
You are talking about a "build system". MSVS is not that. It is an IDE, which happens to permit you to organize your assets into projects-and-solutions, and yes, to "build". But, it is not a build system. It will never be a build system (long story, but a very different technology is required).
In contrast, MSVS is an IDE for accelerated iterative development, including the "debugging" cycle (e.g., "step-into" and "step-over" in the debbugger during system run). That's where MSVS "shines".
It does not, and will never, "shine" as a build system. That's not what it was created to do. And, this will likely never change (long story, even Microsoft will likely agree).
I'm not trying to be cute, and I sincerely apologize for delivering this news. This answer hurts me too.
I expect working incremental compilation of solutions. Especially in
product like VS 2010 Ultimate which costs several thousands dollars.
MSVS is an IDE for interactive debugging/development, and not a build system (see above). So, you are measuring it in a product scenario for which it was not designed, and in which it will likely never function as you desire.
I really don't want to get answers like:
Make a separate solution
Unload projects you don't need
etc.
I can read those answers . Those are not acceptable solutions.
We're not paying for VS to do such compromises.
Your expectations are reasonable. I want them too. However, MSVS is not a product that will ever deliver that.
Again, I'm not trying to be "cute". If you are willing to invest in a "build system", you may find value in using something like CMake to manage your configurations and export Makefiles (or something) to perform your "real" builds, but to also "export" *.vcproj and *.sln files for when you want to do work iteratively and interactively within the MSVS IDE.
EDIT: Rather, what you want is a SSD (solid-state-disk) for your build workspace to get a 10x improvement-in-speed, or a RAM disk for a 100x improvement-in-speed for builds (not kidding, 64MB RAM on an LGA2011 socket gives you a 32MB RAM disk, which is what we use.)
One things you can do is to break your app into small solutions, each one being a cohesive part. Build each solution separately. Have each solution use the outputs of the solutions it depends on, rather than using the source code.
This will allow for shorter feedback cycles for each component
EDIT: Modified Solution
Additionally, you will create an integrative build that rather than getting all of the sources, compiling and testing, it will get the binary build products of the component CI builds. This integrative build should be triggered to run after every successful component build.
This build should be the binary equivalent of a complete build (which you still should build every night), but will take considerably less time to run, because it triggers after a component increment and doesn't need to compile or get any sources.
Moreover, if you use an enterprise grade build system that supports the concept of distributing your builds among multiple agents, you will be able to scale your efforts and shorten your complete CI cycle to the amount of time it takes to build the longest component, and test the integrative suite (at most).
Hope this helps.
Weighing a bit late on this, but have you considered having different build configurations?
You can tell visual studio not to build certain projects depending on the build configuration.
The developer could simply select the configuration relevant for the project their working on.
Pretty ancient thread, but I can say I was suffering from a smaller version of the same thing and I upgraded to Visual Studio 2012 and the problems seems to have finally been fixed. The RedGate .NET Demon solution mentioned above also seems to work pretty well so far.
This is an old problem.
Use parallel build and SSD . See here (I think - quick google):
http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx
I found a tool which does mostly what I want (and even more): RedGate .NET Demon. It is probably still the first version because I encountered few issues in our big solution (problems with C++ projects, problems with switching build targets and few others) but I really like it so far. I especially like the way how it tries to track changed files in VS IDE and rebuilds only affected projects.
Edit: .NET Demon has been retired as it should not be needed for VS 2015. It still works with previous versions.