envdte package shows up as soon as Tmds.ExecFunction is installed

[tisis2]

since 0.6.0 in the package explorer of VS the envdte package will appear, since this is not added as a dependency but by targets file as its own package. this will also cause this package to show for updates.

if there is really no other possibility to auto attach debugger and solve the dependencies, all this should be at least in its own package.
maybe there should be an auto attach package that uses that envdte as dependency, so you dont need any copy tasks and this package can only be installed when debug config is chosen

[Bertk]

Hi,

By the way, when will the EnvDTE version upgraded to 17.7.37355 (VS2022 version).

[tmds]

I won't be looking into this myself as not that many people have responded to this issue so far, and I don't want to break VS users. Because I don't use VS, I can't validate the change.

If someone has a fix for this, feel free to suggest it in a PR.

By the way, when will the EnvDTE version upgraded to 17.7.37355 (VS2022 version).

I'll be upgrading this for an upcoming release.

[Bertk]

FYI. We can currently not use .NET 7.0 feature (Central package management for a test project which uses Tmds.ExecFunction because this triggers a nuget restore loop in VS2022.

[tmds]

I'm open to PRs to fix and improve this, but as a non-VS user, I can not help provide them.

[tmds]

I had accidentally broken the vs code debugging in v0.7.0.
While fixing it, I've added some bits that should make it work with central package management.
This is part of v0.7.1 which was just published to nuget.org.

[tmds]

@Bertk when you had a change to try 0.7.1, please let me know if the central package management issue is fixed.

[Bertk]

@tmds Yes, I could activate central package management for the test and now also use VS2022. Thanks.

[smaillet]

I think the issue here (at least from me) is that it appears as a TOP-LEVEL package instead of as a dependency. It is VERY frustrating to have a mysterious dependency show in the UI as top level but NOTHING in the project actually references it. ALL other packages show dependencies of the package as children so it is easy to identify the source of the inclusion (For rapid CVE response etc...)

NOTE: After digging into it the problem is that Tdms.ExeFunction.targets includes a PackageReference element. Implicitly referenced props/targets files should NEVER do that! The source of the reference is extremely difficult to find when dealing with updates/CVEs. Instead, the package itself should have any dependency information. I don't know what such a reference is for as there's no docs, but it does seem to be conditioned on EnableExecFunctionVsDebugging property (again no idea what that is as there's no docs) but setting that to false at least removes the mystery dependency.