When learning about .NET Core, I heard that it would be possible to edit .CS code while debugging (e.g. controllers). Now that we're at .NET Core 2, I still can't find a way to get this to work.
This all stems from working with PHP/JavaScript developers who absolutely hate, with reason, the lack of editing while debugging. You have to stop the app, edit the code, run, wait for build, and then see it. I get it's because of the compilation, but I thought they were changing something in .NET Core and VS 2017. This even goes down to stupid things like adding images to your project.
Any ideas on how to enable some of this?
The answer is yes and no.
There are "watchers" in .NET Core that means your code is constantly recompiled as you make changes. To do this you just add this nuget package :
Install-Package Microsoft.DotNet.Watcher.Tools
And then run the watch command from your command line tool :
dotnet watch run
But again, this is simply recompiling your code as fast as possible so that when you refresh in your browser, the live changes are there. It's similar to other watches in things like Gulp etc.
It's possible to "attach" the debugger to your running instance, but as soon as your code is recompiled you need to reattach the debugger. If you are looking to be able to use breakpoints while using watchers for example, I don't think it's possible.
More info :
https://dotnetcoretutorials.com/2017/01/31/live-coding-net-core-using-dotnet-watch/
https://learn.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
Related
I have a simple MVC Web application in the .NET Framework. To run it, I can click the green arrow ("play" button) in Visual Studio, which does a "build" and starts a Web browser pointing to the application.
Or, I can just start up IIS Express with the proper command line options, and navigate to localhost:8080 in a browser and run the application without a "build".
What is the purpose of "building" the application in Visual Studio if it runs fine without it?
The simple answer is that it doesn't run without the build step; your assumptions are wrong.
However, Visual Studio continuously monitors your source files and compiles them, e.g. to be able to show intellisense suggestions and compiler errors while you type. This means that there are in fact compiled binaries based on your source somewhere, maybe just not in the bin folder under your project root (that somewhere might be in memory, or in some cache location on disk, depending on circumstances out of scope for this question).
It's also very likely that you've previously built your application, resulting in binaries in your bin folder, even if you didn't do it with the purpose of running the application right after. In either case, if you get it working with IIS Express it's because it can find compiled binaries somewhere, and run those.
The main reason to have Visual Studio explicitly rebuild your app when you hit play, is to make sure that you're running the latest version of your code. Sure, it takes a few extra seconds every time you start the debugger, but it's nothing compared to the time you'd lose trying to track down a bug that you've already fixed in your code, but which still manifests in the running application, because the running application is an outdated version. (It also makes things like stepping through the code much less confusing, since, again, the source code on file will always be in sync with the running application.)
I've just written the first version of a workflow activity that will run Resharper's Code Issues on the projects and parse the output to display the issues as build warnings and errors.
At first, I was going to just call Resharper's command line and parse the resulting xml manually. After fiddling with the dlls in Resharper's SDK (through disassembly mostly), I found a way to parse the results using it's own public classes, which I figured was a much more elegant and safe way to do this.
The first problem I have is that that nuget package is absolutely huge. There is 140mb of files in there, which to me is absurd for a single, unpartitioned package. There seems to be such heavy coupling between them that by using just a few model classes and the parser class, I have to drag a dozen or so of those dlls along, some of them which seemingly have nothing to do with the main dlls I need. This is not a show stopper though, I'm struggling with something else now:
In the end, I managed to track down the dependencies I needed to 41 assemblies (which is, again, insane, but alas). Initially, I tried removing everything and adding the missing references one by one, but this turned out to be unreliable, still missing some indirect references, even after compiling successfully. Then, I decided to code a small console application to find all referenced assemblies in the main Resharper assemblies I used, which gave me the 41 references I mentioned. This is the code I used to find every dependency.
Since these are custom activities we are talking about, I decided to create a unit test project to validate them. Using these 41 references only, everything works correctly.
When I added the activity to the build workflow though, and pointed the build controller to the source control folder containing the required assemblies, every time I schedule a build, the process fails stating that I need one extra dll from Resharper's SDK. For example, this is the first one it asks:
Could not load file or assembly 'AsyncBridge.Net35, PublicKeyToken=b3b1c0202c0d6a87' or one of its dependencies. The system cannot find the file specified. (type FileNotFoundException)
When I add this specific assembly to the TFS folder, I get another similar error for another dll, and this keeps going on and on.
What I wanted to know is how can I know exactly which assemblies a workflow XAML will need in order to run correctly? My custom activity dll has two specific CodeActivities and a XAML only activity that uses these two. This XAML acticity is what I'm directly using in the modified workflow template.
I see that besides the references in my project, the XAML activity also contains a TextExpression.ReferencesForImplementation section, with some assembly names. I've run my dependency finder program on those dependencies too, and the results are the same 41 assemblies already at the TFS folder.
Meanwhile I'll go with having the whole SDK into the custom assemblies folder, but I would really like to avoid this in the future since it has such an enormous amount of unneeded and big dlls in there.
First, we have request for our command line tool to support workflow activity and we decided to implement just plain MsBuild task which is universal and works in TFS too. Task and targets files are included in ReSharper CLT 8.2.
Second, if you still want to implement workflow activity it's pretty easy to do with new API in CLT, designed specially for custom processing of found issues - http://confluence.jetbrains.com/display/NETCOM/Custom+InspectCode+Issue+Logger.
And last, but not least, you do not need to put in VCS binaries of ReSharper SDK package.
Use NuGet's restore package functionality.
If you have any other questions I'll be glad to answer them.
A custom activity is being load and run by .NET CLR like any other .NET program. If the stack trace reports a missing file, then it's required by the CLR and you can't change this fact without refactoring your code.
Having an entire SDK references in the custom assembly folder doesn't make sense. I would prefer GAC deployment over huge binaries folder in the source control. Or maybe consider having these activities running an pre\post build scripts in MSBuild or PowerShell.
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
I have a project group containing two projects that share one source folder,but do different things.What I find strange is the use of 'project group',but I don't want to turn this a subjective question,thereby I directly ask you:
How do I run all the projects in a project group - is there a short way?
Thank you in advance!
Actually, all of you are wrong. You can debug multiple programs at the same time.
I don't know when this was first implemented, most probably when the project groups were added to the Delphi, but I'm using this since "forewer" and I'm sure that at least Delphi 2005 was capable of doing it.
In short:
Create a project group with two programs.
Build them all! You won't be able to use the compiler after you start the debugger.
Activate the first program (double-click on its name in the Program Manager) and press F9 (run).
Activate the second program in the Program Manager (you cannot use the drop-down next to the "Run" toolbar button for that as it will become disabled in the previous step) and press F9.
Voila! You have two programs running under the debugger. You can set breakpoints in any of them and they will work just file.
This approach works with any number of programs. (There may be some hardcoded limitations but I've never run into them.)
The debugger can debug only one application (actually: Process) at the time, and if you run from the IDE it is in the debugger.
So I think the answer is : you can't.
Well, I guess unless you count dlls that are launched in the same process, but are individual projects. (seeing the other post), but I never tried that.
To run all the projects at once, add a new batch file to your project group. Make the batch file run each program, and when you want to run them all later, simply choose the batch file in the project group and run it. This isn't the same as debugging all the projects, just running them. It's simply a way to automate the procedure given in Bruce's answer.
You can only debug one project at a time, but you can run as many as you like from the IDE without debugging.
Shift + Ctrl+ F9
Update: I stand corrected. You can debug multiple projects at the same time. Excellent for debugging a client and a server at the same time.
The projectgroup is a tool to build multiple projects.
You can select build all from here to build them all.
You can run several from within the debugger if one is a program and the others are dlls that are used by the program.
Multiple programs's can't be run/debugged at the same time.
Although you can use a program as a DLL but I'm not sure if the IDE can handle that use. In that case you can use a main procedure which is the only thing called from the main program. Then you should export this main proc. Create an additional exe project that calls all of them from different threads. I have not tested this. And it is a hack, but it could probably work.
But why do you want to run/debug several apps at the same time?
As a side note: Check all dependent projects (right click on project -> Dependencies) to have them build automatically before debugging.
I'm using TJvPluginManager in the JVCL to create and load BPL-based plugins for my program. Problem is, one of the plugins isn't loading properly, and I can't debug it. Every time I try to trace into the loading sequence, it gets as far as the LoadLibrary API call, and then the debugger seems to forget what it's there for. It completely loses the ability to associate program code with source lines, give meaningful data in a call stack, or display local variables. It will still stop at breakpoints, but it breaks to the CPU window, with all the inline source code stripped out.
This happens on Delphi 2007 and 2009, and it's driving me nuts. Does anyone know how to load a plugin without it breaking the debugger? Does anyone even know why it's breaking it in the first place?
NOTE: I'm not looking for alternative methods of debugging. I know all about tracing and logging and all the rest. What I want is to understand what's going wrong and how to fix it. Surely I'm not the only person who's ever used TJvPluginManager?
Not quite the answer to your question: Have you tried to debug the package project, by setting the host application and putting a breakpoint into the package's startup code?
I've found Ray Kanopka's (Raize) CodeSite to be invaluable for debugging in situations where the integrated debugger is acting up. Thinking about the things I want to monitor using CodeSite actually helps me focus on what's important - it enforces good habits.
Another alternative to Codesite is Overseer which is part of the nexus project, but stands alone so does not require you to use their framework. Codesite is by far the better option, but in a pinch Overseer would work just as well.
I found that using packages for plugins can be problematic and many years ago switched to a completely COM based implementation for plugins and never had any problems. The other advantage to COM based plugins, they don't require Delphi to write, do not need to be recompiled when the main app switches to a new version of the compiler (my plugins compiled with Delphi 5 still run fine against the main application compiled in Delphi 2009!) and they are easier to write test applications to assist in debugging.
The only side effect I notice, is that shared code ends up in both executables and the plugins require registration into the registry.
Hmmmm... This is a stupid question, but I have to ask: the initialization function have the EXACT declaration syntax like the other plugins that work ?(from your question, I deducted you made some others that work)
Check your dependencies. Make sure each unit is compiled into one package only. Whenever a package needs to reference a unit from another package, use the requires clause to do so. Watch for compiler warnings about implicitly linked units.