Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert Clasp into a source package #72237

Merged
merged 1 commit into from
Mar 20, 2024

Conversation

dibarbet
Copy link
Member

@dibarbet dibarbet commented Feb 23, 2024

Converts clasp into a source package so we can make breaking changes without breaking consumers in VS. This package is not used for cross component communication (its an internal utility package).

In order to avoid a triple insertion, we still create a normal dll for insertion into VS. This can be removed when all consumers have updated to the source package version. That and additional cleanup is tracked here - #72251

Passing RPS - https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/532565

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Feb 23, 2024
protected readonly ILspLogger _logger;
#pragma warning restore IDE1006 // Naming Styles
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar to the public api, modifying this would be a breaking change. So suppressing until after all consumers switch to the source package.

@@ -1,42 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These were no longer used. the strings are in the protocol project. Additionally there was no resx file for any of these.

@@ -36,6 +36,9 @@
<PackageReference Include="Microsoft.ServiceHub.Client" />
<PackageReference Include="Microsoft.VisualStudio.Debugger.Contracts" />
</ItemGroup>
<ItemGroup>
<Compile Include="..\..\Compilers\Core\Portable\InternalUtilities\IsExternalInit.cs" Link="Utilities\IsExternalInit.cs" />
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like a bunch of projects were picking up this from the clasp project. Had to add it in a few places now that its become a source package.

@dibarbet dibarbet force-pushed the clasp_source_package branch 2 times, most recently from bb7a37b to a4c1d86 Compare February 24, 2024 00:24
public abstract class AbstractHandlerProvider
#else
internal abstract class AbstractHandlerProvider
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The source package versions of these types need to be internal. Otherwise someone referencing Clasp directly, and MS.CA.LanguageServer.Protocol (for example, Razor) will get conflicting type definitions if they're public.

However, for binary compatibility in VS on the old non-source package versions of clasp, these APIs need to be public. So until we move all consumers to the source only version of the package, we have to ship the dll in VS with public accessibility.

@@ -2,6 +2,9 @@
// The .NET Foundation licenses this file to you under the MIT license.
// See the LICENSE file in the project root for more information.

// This is consumed as 'generated' code in a source package and therefore requires an explicit nullable enable
#nullable enable
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we ship an .editorconfig in the package that marks all the code in here as generated code. This ensures that analyzers do not report diagnostics for these files when included as a source package (compiler warnings are still reported - unfortunately there is no way to disable that).

And generated code requires explicit nullable defines in order to use nullable annotations.

@dibarbet dibarbet marked this pull request as ready for review February 29, 2024 17:45
@dibarbet dibarbet requested review from 333fred and a team as code owners February 29, 2024 17:45

namespace Microsoft.CodeAnalysis.ExternalAccess.Xaml;

internal interface IXamlRequestHandler<TRequest, TResponse>
: IRequestHandler<TRequest, TResponse, XamlRequestContext>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was incorrectly exposing the clasp type directly to XAML. making it internal broke their handlers. However XAML already wrapped this handler into a Roslyn typed handler (XamlRequestHandlerBase), so all we need to do here is copy the old signature directly here and remove the inheritance.

@dibarbet
Copy link
Member Author

/azp run roslyn-integration-CI

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

<PackageReference Include="StreamJsonRpc" />
</ItemGroup>
<ItemGroup>
<Compile Include="..\..\..\Compilers\Core\Portable\InternalUtilities\IsExternalInit.cs" Link="Utilities\IsExternalInit.cs" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consuming the ISExternalInit package still isn't an option, I assume?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one? https://www.nuget.org/packages/IsExternalInit. I guess probably possible, but we don't own it and its one less dependency to manage, so I'd rather just use our version.

<Import_RootNamespace>Microsoft.CommonLanguageServerProtocol.Framework.Shared</Import_RootNamespace>
</PropertyGroup>
<ItemGroup>
<Compile Include="$(MSBuildThisFileDirectory)AbstractHandlerProvider.cs" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AbstractHandlerProvider.cs

Out of curiosity, why not an all-inclusive glob?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was autogenerated by VS - also seems to match what other shared projects do (probably because they were also autogenerated)
https://github.com/dotnet/roslyn/blob/main/src/Dependencies/PooledObjects/Microsoft.CodeAnalysis.PooledObjects.projitems

Copy link
Contributor

@ToddGrun ToddGrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@RikkiGibson RikkiGibson self-assigned this Mar 14, 2024
@dibarbet dibarbet merged commit bfa6269 into dotnet:main Mar 20, 2024
27 checks passed
@dibarbet dibarbet deleted the clasp_source_package branch March 20, 2024 21:42
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Mar 20, 2024
@RikkiGibson RikkiGibson modified the milestones: Next, 17.10 P3 Mar 25, 2024
dibarbet added a commit to dotnet/razor that referenced this pull request Mar 26, 2024
### Summary of the changes
Now that dotnet/roslyn#72237 has merged on the
Roslyn side, we need to update Razor to consume the source package
version. This will allow us to delete the nuget package version

-

Fixes:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants