This caused some deployment issues in CB, and there is a hot fix that CB needs that got trapped in between cleanup waves. Reverting so CB can get unblocked.
* Removed now unnecessary 'dependentPackageIdsToSkip'
* Removed remaining unnecessary 'withQualifier' and the general netstandard2.0 forcing that happened on cache specs side
* Reorganized asptnetcore assembly references. This could be simplified further in the future, but now it is more self-contained.
* Some other minor cleanups
Next step is trying to make sure dependency versions are the right ones and try to turn on the flag that enforces this from the nuget resolver.
Revert "Merged PR 765049: DScript spec cleanup wave 2
* Removed now unnecessary 'dependentPackageIdsToSkip'
* Removed remaining unnecessary 'withQualifier' and the general netstandard2.0 forcing that happened on cache specs side
* Reorganized asptnetcore assembly references. This could be simplified further in the future, but now it is more self-contained.
* Some other minor cleanups
Next step is trying to make sure dependency versions are the right ones and try to turn on the flag that enforces this from the nuget resolver."
Reverted commit `2b01690d`.
* Removed now unnecessary 'dependentPackageIdsToSkip'
* Removed remaining unnecessary 'withQualifier' and the general netstandard2.0 forcing that happened on cache specs side
* Reorganized asptnetcore assembly references. This could be simplified further in the future, but now it is more self-contained.
* Some other minor cleanups
Next step is trying to make sure dependency versions are the right ones and try to turn on the flag that enforces this from the nuget resolver.
Turn on the (temporary) flag that enables the correct treatment of nuget dependencies when monikers are used to specify them.
This caused a bunch of issues that are fixed here as well, caused by packages now containing more dependencies than what they used to:
* Some dependencies were plainly missing, so they are included now
* Some packages were causing double-deployment errors, so new 'skipNuget..' clauses had to be added
* On the plus side, some specs got simplified and we don't need to pin particular qualifiers.
The plan is to make this temporary flag the default after this gets merged
```
SetSite failed for package [BuildXLVsPackage]Source: 'BuildXLVsPackageDev17' Description: Unable to cast object of type 'Microsoft.VisualStudio.CommonIDE.Solutions.CSlnUpdate' to type 'Microsoft.Internal.VisualStudio.Shell.Interop.IVsSolutionBuildManagerPrivate'. System.InvalidCastException: Unable to cast object of type 'Microsoft.VisualStudio.CommonIDE.Solutions.CSlnUpdate' to type 'Microsoft.Internal.VisualStudio.Shell.Interop.IVsSolutionBuildManagerPrivate'. at BuildXL.VsPackage.VsProject.ProjectFlavorFactory..ctor(BuildXLVsPackage package) in \.\Public\Src\IDE\VsIntegration\BuildXLVsPackageShared\VsProject\ProjectFlavorFactory.cs:line 59 at BuildXL.VsPackage.BuildXLVsPackage.<InitializeAsync>d__15.MoveNext() in \.\Public\Src\IDE\VsIntegration\BuildXLVsPackageShared\BuildXLVsPackage.cs:line 137
```
The problem is that the extension has its own definition of Microsoft.Internal.VisualStudio.Shell.Interop.IVsSolutionBuildManagerPrivate copied from Microsoft.Internal.VisualStudio.Shell.Interop.10.0.DesignTime.dll. The solution is to use the interface defined in Microsoft.Internal.VisualStudio.Interop.dll.
- Dev17 extensions must be build separately from older versions, as the 32 bit versions are not compatible with the amd64 process used for vs2022,
- Pull managed code into a separate shared directory.
- Update VS SDK package versions to preview versions for dev17.
- Create a second dev17 extension (which is a copy of the older extension with references to newer versions of the VS SDK). This extension will only install on dev17, and has a target architecture of amd64.
- Compile the shared code using the newer and older versions of the SDK for each extension.
- Update extension version to 3.1
- Tested on BuildXL and OSGTools generated solutions with vs2019 and vs2022.
Related work items: #1869107, #1870020
Expose the analyzers support from the Bxl sdk.
Bxl supported Roslyn analyzers for a long time, but the list of supported analyzers was built in into Bxl Sdk.
This PR exposes `analyzers` properties and every project may add extra analyzers if needed:
```
@@public
export const dll = BuildXLSdk.library({
assemblyName: "BuildXL.Cache.ContentStore.Distributed",
sources: globR(d`.`,"*.cs"),
analyzers: [importFrom("protobuf-net.BuildTools").pkg]});
```
Oleksii Kononenko
Michael Pysson
Serge Mera
Julian Bayardo
Pasindu Gunasekara 🍣
Chad Su
Iman Narasamdya
Sergey Tepliakov
Aleksandar Milicevic
Danny van Velzen
Microsoft Open Source