Very long build time in Visual Studio - vb.net

I've a solution with 15 projects (14 class libraries and one web application). Each class library has corresponding test project (i.e. if I have MyApp.Services project there exists MyApp.Services.Tests -- using NUnit). Everything is written in VB.NET. The problem is that when VS tries to compile any of *.Tests project it stops responding (the bigger the project the longer the period without reposnse). I don't know where to start looking for an issue. I'll add that I've R# 4.5 installed.
UPDATE 1:
Is there any way to benchmark a build in visual studio? To get build times for every project?
UPDATE 2:
It seems that there is no difference after disabling R#.

Try turning on verbose logging for the build
Tools...Options...Projects and Solutions...Build and Run..."MSBuild project build output verbosity"
This should help you get a better picture of what is going on.

Disabling Resharper will probably help.
As for the benchmark, try building with msbuild with the following options, it will print statistics on build process at the end.
msbuild yoursolution.sln /verbosity:diagnostic

Try closing the tool panes associated with unit testing.

Have you tried disabling Resharper 4.5, using the Tools->Addins menu, and tried building again?
Also, is there a difference in time if you shutdown VS, restart it and load your solution and try building again before you do anything else. It might be that the build times get slower over time?

Related

VS 2022 hangs after unloading a project everytime

I have a react project which I need to unload from my solution because I build it separately.
Every time I try to unload that project, my VS 2022 goes into a hung state.
Has anyone experienced the same?
Yes, I was experiencing this same thing until just now with VS 2022 Community v17.2.6.
I was trying to unload a GraphQL since I don't really care about that project, it's only on the same folder/repo.
I went into Tools -> Get Tools and Features... and uninstalled Node.js development. That did the trick, although I guess it might be because now it doesn't load the project to start with, it shows as "incompatible". Luckily I don't do any Node.js development in VS.
If yours is a Node.js project too you could try this, or maybe try a fresh install only including the most basic things to see if it works that way, and keep adding tools and features until you find which one is the problematic one.
I am also experiencing the same problem.
In my case, it happens when I switch branches with the VS solution open. It hangs while trying to unload one or more projects. The solution has ASP.Net MVC and C# projects.
So far I didn't find how to fix this.

MSBuild always build all platforms even when specific one provided

Any ideas as to why MSBuild is always building all my platforms for my UWP solution even though I'm specifying to only build for the ARM platform. This is the command line I'm using:
MSBuild.exe C:\MyApp\MyApp.sln /p:Configuration=Release /p:Platform=ARM
Am I missing something or doing something wrong?
Thanks.
UPDATE - 1:
I've also tried specifying x86 as the platform, but it still builds all platforms.
After spending hours trying to figure out this problem, I have eventually figured out what's wrong, well partially at least!
As mentioned, the above does not work as expected, unless I first create a package via the .NET IDE and only select a single platform. Once I do this, the above command line will build the relevant platform that's specified in the command line!
I've just tried it again and created a package via the .NET IDE and re-selected all platforms and called my original command line once again, and it build all platforms rather than the one specified in the command line. There is obviously something in the solution file that's causing this but personally I think this behaviour is wrong and is a bug.
The following command lines seem to worked irrelevant of what has been selected via the .NET IDE:
To only build a package for ARM in Release mode:
msbuild "c:\myapp\myapp.sln" /p:configuration=release;platform=ARM;
AppxBundle=Always;AppxBundlePlatforms="ARM"
To only build a package for x86 in Debug mode:
msbuild "c:\myapp\myapp.sln" /p:configuration=debug;platform=x86;
AppxBundle=Always;AppxBundlePlatforms="x86"
While the above works, irrelevant of what's selected in the .NET IDE, I haven't figured out how to build all platforms.
I'll also investigate the original command line problem and the link with via the .NET IDE selection, and I'll update my answer if I find out what's causing it.
Hope this helps.

Visual Studio 2012 doesn't find tests from a project

I know that this question has been answered here, Visual Studio 2013 doesn't discover unit tests , and I also have searched at many forums, but after 6 hours, I still haven't found a solution for this.
In a solution with several projects, I have some test classes in almost all projects. Tests are done with the library Microsoft.VisualStudio.TestTools.UnitTesting (10.0) of Microsoft. I also have Resharped installed. Since today I can't execute test methods from a project. The tests of the other class are being executed right, but in one class are not being executed anymore.
If I execute tests with Resharper I get this message error: Inconclusive: Test wasn't run.
If I disable Resharper and execute tests with VS I don't get any message error, but tests don't execute.
I have checked all these solutions but not any of them work:
Disable Resharper
Clear test cache
Remove temp directory from my system drive
Enable/Disable shadow-copy
To check that the directory of the project is not shared.
To delete .suo file from solution
And tests of this .dll not yet work.
Any suggestion?
Thank you very much.
It's already solved. It was because Nuget dependency conflicts.

TFS 2013 BuildAgent hanging while building solution

We have a problem with the TFS build agent intermittently hanging while building our solution. We have some custom build actions, we're using eazfuscator, and we have some post build actions as well.
So it's quite possible we are causing the problem. We've identified that the solution (filled with C# projects) starts compiling but does not finish. What we need is the log file from MSBuild/csc, but because the solution never finishes, those logs never go to the build drop.
I need help finding the log file on the build agent. Any ideas?
Thanks!!
I suggest you to copy the MSBuild command which is generated in TFS build for code compilation, run the same command on build agent server manually from command prompt. Here, you will get more details to figure out the cause build for hanging issue.

VB.NET - Application has encountered a user-defined breakpoint

I'm not that up on VB.NET, the application I'm working on was not written by myself.
It works fine through the IDE but once I run it from the exe it gives me the above error.
Any clues?
This is really hacking me off!
The only user defined break point that I can think of is
Debugger.Break()
So, I would suspect that the .exe is compiled in debug mode. I would recommend Reflector to look at the code and find out for sure whether or not there is a Debugger.Break() somewhere in there.
Afaik, the only way this could occur if you are compiling under debugging settings. You should be able to fix it by doing the following:
Right-click your solution on the
solution explorer.
Select configuration properties.
At the top of the dialog box there should be a
combobox, which will most likely say
"Active(Debug)".
Click on the dropdown and select release.
Ok out of everything.
Build > Rebuild Solution.
Source: p2p.wrox.com
I believe the exe file was compiled using the "Debug" setting. Try changing the Build setting to Release and do a full build (rebuild) of the project. Then try to run the executable file. It should then run normally.
The reason you see that error is because when you normally compile and run applications in Visual Studio, it compiles a Debug build of the executable. The different between a debug build and a release build is that the debug build has additional information added to it, by the compiler, so it can be debugged properly.
I would suggest looking for stop in your code. That is what generated this error for me.