Closed ssemon closed 2 years ago
GUID Constants object:
public static class Constants
{
public const string DebugEngineName = "Intime Debugger Engine";
public const string DebugEngine170Id = "70A6FCFC-1A0A-4B61-A320-FD28F92D3732";
public const string DebugEngine170ClassId = "2A3220C9-8CA7-4F05-8747-520D6A78B61B";
public static readonly Guid DebugEngine170Guid = new Guid(DebugEngine170Id);
public const string PortSupplierName = "Intime Debugger Port Supplier";
public const string PortSupplier170Id = "E844B652-8854-478F-8237-206BCAFFDC4F";
public const string PortSupplier170ClassId = "C644EA21-DE61-4D47-A7E0-58B4BF26F1DA";
public static readonly Guid PortSupplier170Guid = new Guid(PortSupplier170Id);
}
Class Definitions:
[System.Runtime.InteropServices.ComVisible(true)]
[Guid(Constants.DebugEngine170ClassId)]
public class Engine : IDebugEngine2, IDebugEngineLaunch2, IDisposable
{
//.........................
//Implementation
//...........................
}
[System.Runtime.InteropServices.ComVisible(true)]
[Guid(Constants.PortSupplier170ClassId)]
public class PortSupplier : IDebugPortSupplierEx2, IDebugPortSupplier2, IDebugPortSupplierDescription2, IDisposable
{
//.........................
//Implementation
//...........................
}
Hello, I am happy to try and help.
Questions:
I feel like I'm missing a step somewhere between 2019 and 2022 extension support. I've followed the instructions on Migration as Microsoft Instructs. Building all assemblies as x64,. Updated to package references.
In both cases the visx load and run correctly, but fail to find both assemblies.
============================================================== Next are the screen shots.
2019:
Constructors and Assemblies Loaded for 2019:
======================================================= 2022 same steps:
Hello Gregg, I've also attached a screenshot of the diff between the two pkgdef files thinking the issue resides there.
The main diff is the GUIDs which match in the previous comment.
@ssemon:
Sorry, you grabbed Process Explorer screen shots, but I would actually recommending Process Monitor so that hopefully we can see what file/registry key/etc is "not found".
A few other notes in case they are helpful --
Thanks Gregg, 1) The clarification, will make things simpler using the same guids for different visual studio versions, and targeting Any CPU will help in this case. 2) My bad, I misread your comment, I'll have something on Monday showing the Process Monitor. Best Regards, ssemon
Hello Gregg, unfortunately, works dns went down yesterdsy (I work from home), and IT is working on it, so I haven't been able to get data yet.; I'll keep you posted. Thanks for the help.
Hello Gregg, I looks like it's not finding the port supplier.
Not sure what to do about it though.
Best Regards, Ssemon
Are you filtering the results to just failures? I am not sure that it is actually failing because the next row after the failure for '..._Config\AD7Metrics\PortSupplier\{E844B652-8854-478F-8237-206BCAFFDC4F}' is probing at your CLSID, which seems to imply that it successfully read 'PortSupplier\\<Your-Guid>\CLSID'.
If you want to double check that your .pkgdef is successfully making it to the registry, you can use the VsRegEdit.exe tool.
Example: C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE>.\VsRegEdit.exe read local Exp HKLM AD7Metrics\PortSupplier\{E844B652-8854-478F-8237-206BCAFFDC4F} CLSID string
It's actually probing at the shell class id:
But never finds the classId for the port supplier which is: C644EA21-DE61-4D47-A7E0-58B4BF26F1DA
Attached is the PortSupplier.PML, as a zip, perhaps you may see something, that I'm missing.
Hi Gregg, it also never gets past the port supplier, to try to load the engine.
Hi Gregg, I was wondering if you would be willing to review the stub project if I zip it up and attach it here. For I'm just trying to get the AD7Metrics Engine and PortSupplier to register correctly. Maybe you might see something I am missing. Thanks, Ssemon
Yes, I would be happy to take a look.
Hi Gregg, thanks appreciate it. Here is the zip. IntimeDbStub.zip Best Regards, ssemon
I had a lot of trouble getting your sample project to build. It is currently failing because GetConfigurationGeneralPropertiesAsync
is missing for me.
A few notes:
vsregedit.exe
command that I gave you above is failing, I believe the issue is that your source.extension.vsixmanifest
doesn't declare an asset for your .pkgdef file. You should have something like <Asset Type="Microsoft.VisualStudio.VsPackage" ... Path="INtimeDebugger.pkgdef" />
RegisterForComInterop
enabled on several of these projects. You shouldn't need that and instead should register things through pkdef files.Reference
items in projects are neither providing a HintPath or using a full path to the assembly. This means that you will wind up pulling whatever version is installed on the box you are building, which is going to be some old version. You want to either convert all the Reference
items to pass a hint path, or convert things to use PackageReference.Hi Gregg,
Sorry about that. GetConfigurationGeneralPropertiesAsync is generated by xaml ruleset.
I'll unzip into and new folder and see why the ruleset isn't generating. I'll fix that.
I'll also fix the 3 items you mentioned.
Finally I'll send the fixed back to you in the zip.
Thanks,
Ssemon
Ah. My fault then on the GetConfigurationGeneralPropertiesAsync
problem -- I was having issues with the XAML stuff due to the hard coded path, so I just commented it out. I had no idea that stuff generated code.
I see, ok, I'll examine that and see how to get it to reference without hard coded paths. The other references were added by project like the IntimeDbConstants, and IntimeDbStub in the Intime project. Not sure why it puts the whole path there.
I found out that the location for general.xml has changes in visual studio 2019, which wasn't updated in out project because it built correctly. It's in C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VC\v170\1033\general.xml So line 146 in IntimeDbStub.csproj needs to change to:
I'm testing the above changes, and will send a new zip. Thanks, Ssemon
It left the xmal comments out in the above csproj changes. So line 146 in IntimeDbStub.csproj needs to change to: C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VC\v170\1033\general.xml Also line 104 in IntimeDbStub.csproj needs to change to: C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\Extensions\INtimeDebugger
Ok the changes were tested below: But still the same dialog pops up. Unable to debug, cannot find file...
1) <Asset Type="Microsoft.VisualStudio.VsPackage" ... Path="INtimeDebugger.pkgdef" /> added to Intime proj. 2) Removed register for COM Interopt. 3) Project references, not sure why I cannot add relative paths. 4) Fixed the csproj file for xaml rules.
Hi Gregg, if you would like to try the platform build and debug settings for Intime you should be able to do so with the following: Unzip Intime_Platforms.zip into C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VC\v170\Platforms or where your Msbuild for visual studio 2022 is.
Attaches is also a test project for the debugger.
This should set it up to step through IntimeDbStub where I fail at.
Thanks, Ssemon
Another note, to build it you might have to add a reference to some headers and libs for microsoft in the test project, because we have modified headers in $(INtime)/rt/include, and libs in $(Intime)/rt/lib, as well as binaries in $(Intime)/bin.
A simple Hello world should work with microsoft settings. And be able to step through the IntimeDbStub
Ok, I found out it took a little work to get the microsoft headers and libs to work. Here is an modification to the test project, using windows headers, and libs. libcxx22test.zip
Hi Gregg, I modified the above IntimeDbStub to work with visual studio 2019 by changing the visixmanifest install targets and prerequisites only. I get the not implemented exception from the Engine stub as expected. Is there anything, I could provide to help anayze the 2022 problem? Perhaps a shared project with both visual studio versions in it? At this point my status is that it looks like it's coming from the Port supplier (as it loads first), but I have no idea what file cannot be found for visual studio 2022.
Hello Gregg, Ok closing this now. Figured out a few extra things like breaking API changes that were confusing at first. This problem wasn't in the pkgdef file at all. Thanks, Ssemon
@ssemon sorry for the delay. Glad you figured it out!
I've created two stubs for the AD7Engine, and PortSupplier. I've also created a visix using the DebugLaunchProviderBase.
However, when hooking with the project I can step though the visix code and public override async Task<IReadOnlyList> QueryDebugTargetsAsync(....)
which sets:
............................
............................
settings.LaunchDebugEngineGuid = Constants.DebugEngine170Guid;
settings.LaunchOptions = DebugLaunchOptions.StopDebuggingOnEnd;
settings.PortName = node;
settings.PortSupplierGuid = Constants.PortSupplier170Guid;
This works with visual studio 2019 all built with Any CPU. Finds both stubs and I can step though them to verify the hooks. However, with visual studio 2022 I reach the end of public override async Task<IReadOnlyList> QueryDebugTargetsAsync(....), and then it complains it cannot find the file specified.
=====================================================================================
PkgDef contents: