Open dazinator opened 7 years ago
I noticed that, in the rule file for the debugger, there is some metadata that hooks up the enum provider to an existing command - I am wondering - could some other rules coming from elsewhere be doing the same thing to add in this additional value? The trouble is I am not sure how I can track them down if that is the case.
<!-- the command which appears in the debugger dropdown -->
<Rule.Metadata>
<sys:Guid x:Key="DebugTargetTypeCommandGuid">568ABDF7-D522-474D-9EED-34B5E5095BA5</sys:Guid>
<sys:UInt32 x:Key="DebugTargetTypeCommandId">0x100</sys:UInt32>
<sys:String x:Key="DebugTargetDropdownEnum">ActiveDebugProfile</sys:String>
</Rule.Metadata>
Could you check the value you have specified in the .props file as DebuggerFlavor? It should point to your Debugger:
Based on the snippets you posted above, it should be something like:
<DebuggerFlavor>DnnWebsiteDebugger</DebuggerFlavor>
Sure - yes it is:
<DebuggerFlavor>DnnWebsiteDebugger</DebuggerFlavor>
In addition, if I select a debug target that I am generating:
I can launch my custom debugger and step through the code and it appears to work fine.
If I select the debug target that is there by default then my custom debugger doesn't get invoked and I see the standard error about the project being a library project:
Perhaps it got persisted initially to the project or the .user file before you added your debugger? If yes, could you try removing it to see if that fixes it?
If I remove this import from my project file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
Then the entry disappears..
So seems this is automatically added when these targets are included..
Right now, Microsoft.CSharp.targets are imported in my project file, and then my project system targets and props are added via a nuget package install. I wonder if removing the Microsoft.CSharp.targets and then adding them after the nuget install is finished will solve this (or importing Microsoft.CSharp.targets them from my custom targets instead) - I'll give that a go!
Perhaps it got persisted initially to the project or the .user file before you added your debugger? If yes, could you try removing it to see if that fixes it?
I can't seem to find a user file anywhere after creating the project. I can't see any additional entries in the project file. Removing the import of Microsoft.CSharp.targets
gets rid of the entry.
I'm experimenting with the order in which targets are imported, thinking perhaps importing Microsoft.CSharp.targets last, may mean it wont add the value anymore (i.e perhaps a default target is only generated if there isn't allready any values generated).
However this seems to be very fragile. I have taken the CSharp import out of the project file, and put it in my CustomProject targets file instead, but now when I create a new project I get this error:
Not very helpful error! Any ideas how I see more information about why project creation failed?
Here is my somewhat educated guess over what is happening.
I am importing Microsoft.CSharp.targets
This is adding some capabilities - causing a managed CPS extension to be loaded for the debugger.
The managed extension is probably implementing IDynamicDebugTargetsGenerator
and is running first, and creating a default debug target because if there are 0 debug targets this will lead to a poor experience if the user tries to debug.
My extension IDynamicDebugTargetsGenerator
is being loaded after the managed one, and adding my own debug targets.
If this is right, all I need is to get my IDynamicDebugTargetsGenerator
to run before the managed one..
How do I do that? I guess there must be an order attribute or something i can use with my export.. i'll try that.
Well, the roslyn project system is open source so you can search directly in the source to see.
So I found DebugProfileDebugTargetGenerator:
which gets activated on the "LaunchProfiles" capability. So you could try removing that capability from your targets:
<ProjectCapability Remove="LaunchProfiles" />
Now, because your project type imports CSharp targets, you will get a mixed set of features. You may also need clean up some of the rules that Project System Extensibility generated in your project as in Visual Studio 2017, C# targets uses a newer version.
Use
msbuild /pp:pp.txt
on one of your project to get a full picture of everything that gets included.
Genius. I forgot you could remove capabilities as well as add them.
Also that msbuild command looks invaluable.
Thank you, much appreciated.
@adrianvmsft - damn. So even though I am removing this capability, this additional debug target is still appearing. Yet if I don't import csharp targets at all then it disappears.
I don't know enough about how capabilities changing works - but I am assuming that importing csharp targets causes Roslyn capabilities to be added, and CPS extensions get loaded straight away - later when I remove those capabilities. it's too late, as CPS has already loaded the parts. Could this be what I am seeing?
Not sure why this was closed.. Can you re-open as this is still an issue for me!
I took a look at the dotnet project system, it looks like this capability only gets included by this target file.
Could you try to comment out that line on your local machine to see if it fixes your issue?
If that is the cause, you should file an issue on the dotnet project system repo, as they own those capabilities/targets.
Thanks, Adrian
I followed the advice of @adrianvmsft and it indeed work properly. It still display "Start" in the profiles list (I've deleted .csproj.user
file), but it's not selectable and don't have an icon (see the attached screenshot) so it's not a problem at all.
Alas, <ProjectCapability Remove="LaunchProfiles" />
doesn't work.
What worked for me is adding this block to my targets file:
<PropertyGroup>
<DefineCommonManagedCapabilities>false</DefineCommonManagedCapabilities>
</PropertyGroup>
And then redefining there the common managed capabilities by copying block of code from target file with commented out <ProjectCapability Include="LaunchProfiles" />
.
@aienabled nice discovery! I will try the same tactic :-) thank you for sharing.
@dazinator I'm also trying to customise Debug Targets for our IoT device list, but finding it hard to find documentation on how to get it all working. Are you able to point me in the right direction? I have the IDynamicEnumValuesGenerator
and also the IDynamicEnumValuesProvider
respective classes set up and also the rule updated to similar to what you have, but my list never appears in the IDE.
Any pointers as MS documentation seems to be lacking and there doesn't seem to be a sample anywhere on how to do this.
I am using a
IDynamicEnumValuesGenerator
to provide enum values to display as targets in the debugger dropdown.However, in addition to the values I am generating, I am also seeing a default value - which looks similar to the one generated for managed projects:
In the above image, I am generating the bottom 2 values, but I am not sure where the first value is coming from - which is the name of the project itself.
I know that managed project system generates a value like this, so I am wondering if perhaps this is making its way into my project system somehow.
My capabilities:
My debugger rule:
My debug targets generator:
and the enum values generator
I have confirmed that in all cases, I am only ever returning 2 enum values, so i can't see where this third entry is coming from.
If you attempt to debug with it you get a standard managed project system error message too: