I have a WebApi project, and an MVC project that consumes the WebApi project through RESTful calls.
I set my VS 2013 Professional system to start both projects at the same time.
If I run either project alone, I can set and capture breakpoints. If I run both projects, only breakpoints in the WebApi project are available. How do I fix this? As far as I can tell, there are no version issues with any common assemblies, and the multitude of answers on SO do not seem to apply.
So apparently the answer is shouting curse words at your monitor. After restarting IIS Express, Visual Studio, and my machine multiple times, Cleaning the solution multiple times, changing the build config back and forth multiple times, it just started working all of a sudden. No code or configuration changes. Whoever said insanity is doing the same thing repeatedly and expecting a different result was clearly not a developer. Either that or I'm insane. (could be both)
Related
I have a solution which contains two microservices and an API gateway. While debugging, the solution requires to run again and again to get insights or fix bugs.
I have tried dotnet watch run but with this I can attach debugger to one project at a time.
Hosting applications on IIS also requires to copy the files to folder every time for small changes as compared to in .NET Framework where it was easier to host applications on localhost and attach to process.
Currently, I have been debugging it using visual studio with multiple startup projects.
Since pressing F5 constantly is repetitive and hectic so is there any other way around to debug multiple projects using dotnet watch or IIS or anything else?
ctrl+F5 can run multiple, but it will not debug. Other solution try run multiple VS studio, but I'm not sure
There is possibly another way. I was also had issues running multiple projects to debug microservices.
I explored a few possibilities:
Docker - didn't help and ate more memory (if our whole stack was .net core this might be the goto)
Auto starting VS projects with a script (better but not quiet the level of control we needed)
Researched all the things that people said (use logging, do tests etc, all of which ignore the fact that we don't all have perfect codebases to work in)
Finally I created something that works well for our team, and maybe it'd work for you?
Dev Launcher is a simple command line utility that you configure with your project information. It's currently aimed at handling .net full framework, runs in (Visual Studio) and .net core runs with (Visual Studio or dotnet run). It is configurable and I'm guessing a person could get it to work with other IDE's such as VS Code, though I haven't tried it.
The main concept is you first choose the projects you'd like to open for debugging. These projects will open in the IDE which is configured (Defaults to Visual Studio). Then you choose the supporting microservices that you'd like to run in the background. If these are written in .net core they will run in a console window, freeing the memory that would normally be consumed by the IDE and debugger.
Curious to see if that'd be helpful for your situation. Also curious what other ideas people have to make debugging multiple microservices better...
I have to set start up project every time I open this solution.
We have total five projects in one solution. Three of them are websites, one is MVC project and the other one is class library. There are lots of projects on my computer and they are not making any problem.
My other colleagues also have the same project and they don't get any problem with it. I tried to clean-build the solution but no luck. We are using tortoiseHG for deployment (even though I commit, colleagues don't have to set start up).
Please suggest where to look? I have Visual Studio 2013 Professional.
I've a solution with several .dll projects, an Asp.NET MVC3 Razor project and an Cloud project.
If I try to compile the solution with the Cloud project loaded, VS2010 gets stuck in "Buil started".
I have to forcefully close VS2010 killing the process and restart. Then the compiling works good once, the next time it will get stuck again.
If I unload the project and set the mvc project as start-up, everything works (but azure of course).
What could be the problem?
Cheers.
Was it by any chance an ASP.NET MVC project to which you added a CloudService project later on or did you start off with a CloudService from the very beginning?
I was in the former situation and I had no end of problems, like not being able to open property pages or deploying the application. It's not quite your issue, but the following article might help:
http://tomkrueger.wordpress.com/2010/07/27/azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0/
As I say, my problems started because I actually added an Azure project to an existing ASP.NET MVC solution and there were some unnecessary settings left over in the web.csproj file.
All I had to do was open web.csproj in notepad and remove all occurrences of the <PlatformTarget> element.
My MVC prjoject was x86 and of course Azure works on x64 only. Even though I had the platform target set up as AnyCPU somehow Azure couldn't quite get along with it.
Maybe cleaning up your project files helps as well.
Almost all of our Windows projects consist of a WCF windows hosted service and then a WPF client application. All of these have usually been split into two different solutions, one for the service, one for the client. This was done for various reasons, but we recently were looking at possibly putting them all together on a new project, which we did. This would mean not having to run two copies of Visual Studio and make it easier for various other things.
Our concern now is being able to edit the WPF client while debuging the service. Many of the developers will keep the service running a large part of the day when making changes in the client. But it looks like with this setup, when you start debuging the service, Visual Studio will not let you edit any of the other code in the solution.
Is there a way around this, so that you could have the service running whenever you want, and still be able to edit the WPF and CS files in the other project? Or should these two parts stay in two separate solutions?
You'll want two instances of Visual Studio: one doing the debugging of the service and the other one for coding.
You could also imagine having the service running without the debugger attached, and only attach it manually when you're ready to launch/debug the client you were working on.
In Eclipse, I have a workspace that contains all of my projects. Each project builds and compiles separately. A project does not interact with another project.
How does this relate to Visual Studio and Projects/Solutions there?
A VS project is it's own entity. It will build and compile by itself. A Solution is just a way to contain multiple projects. The projects don't necessarily need the other projects to compile (though, they can depend on the other projects).
This just lets you conceptually group projects together into one Big Project. For instance, you can have a separate testing project. It depends on the code from the actual project, and should be kept together with the actual project, but it does not need to be in the same exe/dll.
Each VS project builds a single EXE or DLL. The solution is just a collection of related projects.
So VS project:Eclipse project::VS solution:Eclipse workspace.
Another way to look at it is, a solution is a container for projects. For most of my work , I create each tier as a project within a solution so my tree looks like:
My Web App or Win App
Presentation Layer
files...
Business Layer
files...
Data Access
files
Your mileage may vary
#Thomas Owens:
Yes, some (most?) people using Eclipse have more than one workspace. It's what surprised me the most when I first started using Eclipse, so I'm replying here to make this comment more visible.
The thing that may be throwing you off is the following:
In VS2003, everything had a Project file and a Solution file. If you had a Solution with one Project, you could open the Solution and see the one Project. If you opened the Project, it would try and create a new Solution file to contain the Project. But web projects and Winform projects all had Projects and Solutions.
In VS2005 this changed a bit - by default now, Web projects no longer had Project files. They had received feedback from some web developers that didn't like Project files - their take was that if a file is in the directory, it's part of the app. After VS2005 shipped, they got more feedback from developers who did like the Project file notion, so they patched it back in. This is "Web Site" versus "Web Application" in VS2005 (and I can't remember which is which now).
In addition, in VS2005, if you have a Solution open with only one Project, you won't see in the Solution Explorer that there's even a Solution at all, you'll only see the Project (as if it was not in a Solution). Only after adding the second Project will you see that there's a Solution containing them both.
So basically you were on the right track - Solutions and Projects work the same in Visual Studio as they did in Eclipse, it's just some quirks that make things confusing.
A Solution has 0 or many Projects...
There are way too many kinds of web projects in Visual Studio 2008. There are Web Site Projects vs. Web Application Projects and they limit you in different ways. It's a good example of Microsoft providing too many choices instead of focusing on one strong solution. Even within the Web site Project option, there are at least 3 different ways to compile your application.
I found that not always seeing the solution in the Solution Explorer to be irritating. There is a setting in Options->Projects and Solutions->General called "Always Show Solution" which was handy.