I have a solution with a lot of C# projects. The dependencies are not cyclic and when I build a high level DLL it appears to be rebuilding all the project referenced DLLs that it is linked to before running the program.
This seems to be unneccessary because I did not change the code in those DLLs and they are at a lower level so the changes I made in the top level DLL should in no way effect the low level DLLs.
How can I tell visual studio to only build DLLs that depend up the hierarchy chain not both ways.
Go to Tools->Customize
A dialog will open. Go to Commands tab. In menu barradio select Build | Project only. Assign a shortcut to it and use it.
When visual studio checks dependencies, it runs the build process. This is not necessarily building your project. In Visual Studio, if you navigate to Tools->Options...->Projects and Solutions->Build and Run you will see a drop downs labeled MSBuild project build output verbosity. If you change this to Detailed. When you build, you will see, in the output window, that it is verifying whether or not files have changed in order to determine if it should rebuild the project. This is why it appears to be building every time.
You should use the following setting:
"Only build startup projects and dependencies on Run" under Tools / Options / Projects and Solutions / Build and Run.
Related
the problem is thus. Every time I open a specific solution in visual studio it hangs forever, you get the annoying Visual Studio is Busy popup. The only way to get it to load is starting visual studio in safemode or by deleting the v12.suo file before opening the solution.
Once it's hung all the projects are marked (Initializing) apart from one project that is (loading). This project is from a different solution and from a different place in the tfs tree. If I unload the shared project then VS loads the solution fine, I think the problem is with TFS, can it deal with a project in multiple solutions?
Thanks
You should remove the shared solution and instead share discreet components as Nuget Packages.
I would generally have a Solution & Project for each of my shared groups... Usually there is a relationship between the css, images, and JavaScript... And package each one as a Nuget Package. Add an automated release pipeline and you can have checkin->dependancy in very short order.
I use VSTS and have a Build that creates a Nuget package with the bits I need and then use the release management tools to control visibility and quality of that package. It's then easy to have your packages deployed to a Nuget Repository (I use VSTS) and let any of your internal projects take a dependancy on them.
This will have the added bonus of increasing quality and knowledge of dependancies and interfaces in your devs. Let them have a dumping ground and they will always use one.
You can do below steps to narrow down this issue:
Try invoking Visual Studio from the command line devenv.exe /log. Then try to open your solution and then if it crashes, go look at the
%APPDATA%\Microsoft\VisualStudio\<version>\ActivityLog.xml
file. It will including some details on the crash. Also, the event logs may capture some high level events as well.
I have the application (solution in VS2010) with +-10 projects. Some of these projects are quite large (dozens of folders and hundreds of files).
When I make a change in project on lower level and I want to run my tests (+-10 seconds) then I have to wait 2 minutes for projects build.
This is very inefficient.
Is there any way to speed-up build? For example, split current projects into multiple projects or something else?
Or are there some general advice and recommendations to speed-up building projects in Visual Studio?
Try this:
Go to "Tools" menu -> "Options" -> "Projects And Solutions" -> "Build And Run"
And increase the value of "Maximum number of parallel project builds" to 32 or greater.
In my experience solutions with large number of projects build slowly on vs2010 and there is not much you can do about it:
Reduce number of projects - larger single project will build faster then many smaller.
Prepare set of build configurations Build->ConfigruationManager to build only parts of your project since you don't have to build projects that depend on changed project if public interface is not changed. This can be tricky to use and some unexpected errors might occur in runtime. Also make sure that all your projects point to single Bin\Debug Bin\Release folder so that new dlls are loaded on application start. This is requited because if you don't build project its dependencies wont be copied to its output directory.
Upgrade to vs 2012. This is the best option you can choose.
Try to use tools that allow concurrent test execution coupled with shadow building - NCrunch or MightyMoose.
Also try to get rid of unused references - for example move all tests that test only your core project to separate project so that they get executed right after core is built. Try not to use MS accessors, because they force to fully recompile all projects that they are referencing. And of course use SSD disks.
I have built an installer using WiX that consists of multiple .exe files that are 'Release' builds of other .Net projects (VS 2008). Each time I update one of the projects, I build that project and copy the Release build into the installer and then build and release the installer.
I find it a very tedious job to constantly check if the exe's that the installer has are the latest version or not. Is there a way that I can automate this build process so that as soon as I build the installer, it will generate the latest release builds of the associated projects and place the .exe file in the installer project.
I am new to VS and WiX, please advise. Thanks in advance.
You should be able to create a Solution containing:
- all projects which build the EXEs
- the installer project which builds your installer
Once you are there, you should be able to right click on the Installer Project and set dependencies to all the projects which create your EXEs. You should be able to build your Solution with the right EXEs bundled in your Installer.
Arun's solution is great idea, and I recommend it.
We also have a lot of assemblies that we maintain, and rather than copying them around we use symbolic links to minimize the number of build-and-copy actions. You can research mklink (http://en.wikipedia.org/wiki/NTFS_symbolic_link) for details.
We use it like this, but we do this as part of our environment setup, and not part of our build script.
mklink /project1/bin/project1.dll /project2/bin/project1.dll
This ensures for us that project2's reference to project1 is always up-to-date, whenever project1 is build, without needing to copy the file. In our case, project2 and project1 are not part of the same solution, and they have no direct references to one another (we do a lot of plugin-type reflection/assembly loading).
Hope this helps.
When creating a set-up project in Visual Studio 2008, I am trying to create an MSI. I have a standalone installation project - that is, I don’t have a main project to install, I just want to ship some random files.
Configuration properties / build shows that it should create debug/myproj.msi. However, if I do a build of either the solution or the project, I only get an exe.
Do I need to compile this in a certain way to force it to create an MSI?
To build an installer package you must right click on the project and select "Build". Or modify the solution settings to include a build of the installer.
By default installers are NOT built on every build, this is for performance reasons.
I am using testDriven.net and when I right-click and run tests, it appears to build, then runs the test. Only it doesn't really do the build. I keep making changes and the test still fails:) I have to do a VS Build, then run the testDriven.net to get changes to take effect.
This clears up for a while if I delete the solution's .SUO file. Any thoughts?
You already provided the workaround in your answer, which is to build first, then run your tests.
Is your version current?
Release Notes - TestDriven.NET: 2.14
1390: Honour the solution 'Configuration Manager' project 'Build' settings
When running all tests in a solution, only projects with 'Build' checked in the 'Configuration Manager' will be built and executed.
Release Notes - TestDriven.NET: 2.12
1199: Improve support for "Smart Build"
This version should correctly determine when a build is required before a test run. The previous version might incorrectly skip the build if only a non-source project item had changed.
If your only change is to a configuration file (or some other resource that's copied to the output directory conditionally, not a code file) then Visual Studio might skip the compile step. A clean/rebuild will fix this.
To diagnose this kind of problem, try turning up the verbosity of the MSBuild output in the Visual Studio environment. Choose Tools | Options, Projects and Solutions root item, then the Build and Run page. The default for the MSBuild project build verbosity is "Minimal" which is terse but sometimes not enough.