Project capability proposal: [MSBuild.Sdk.SqlProj.BuildTSqlScript]

[ErikEJ]

I have created a PR to add a project capability to a third party build SDK.

The purpose of the Build SDK is to use DacFX to build a .dacpac based on some .sql script.

The capability is useful, as a project using the SDK otherwise appears as a CPS CSharp Netstandard project from the outside.

Any guidance on naming and otherwise?

https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/pull/406

[ErikEJ]

a .sqlproj is somewhat similar to the above SDK, and contains the following capabilities (VS 17.5):

AppDesigner PreserveFormatting CSharp EditAndContinue LanguageService OpenProjectFile CPS SharedImports ProjectConfigurationsDeclaredDimensions UseProjectEvaluationCache HandlesOwnReload .NET Microsoft.VisualStudio.ProjectSystem.RetailRuntime RunningInVisualStudio HostSetActiveProjectConfiguration AllTargetOutputGroups DeclaredSourceItems IntegratedConsoleDebugging Managed PersistDesignTimeDataOutOfProject VisualStudioWellKnownOutputGroups RelativePathDerivedDefaultNamespace SupportAvailableItemName NoGeneralDependentFileIcon ProjectReferences AppServicePublish UserSourceItems CrossPlatformExecutable FolderPublish UseFileGlobs SharedProjectReferences ProjectPropertyInterception DynamicDependentFile GenerateDocumentationFile PackageReferences WinRTReferences SingleFileGenerators DataSourceWindow ProjectImportsTree OutputGroups LaunchProfiles DependenciesTree AssemblyReferences DisableBuiltInDebuggerServices ClassDesigner COMReferences Publish ConfigurableFileNesting ProjectPropertiesEditor Pack

[ErikEJ]

Maybe a better name would be:

MSBuild.Sdk.SqlProj.BuildTSqlScript

[drewnoakes]

I commented on the original issue, suggesting that perhaps an MSBuild property would be a better fit for the use case https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/issues/341#issuecomment-1470894805

If you do decide to use a project capability for this, we generally don't use namespaces in capability names. There is some guidance on capability naming at https://github.com/microsoft/VSProjectSystem/blob/master/doc/overview/about_project_capabilities.md#how-do-i-define-my-own-project-capabilities

[ErikEJ]

@drewnoakes So just BuildTSqlScript as name is fine?

[CZEMacLeod]

@drewnoakes @ErikEJ The documentation does explicitly suggest using namespaces:

Have a namespace prefix, or otherwise sufficiently unique so as to keep the odds of it colliding with a project capability someone else (including outside of Microsoft) might come up with. Good: Microsoft.XYZ.Concurrency Bad: Concurrency

This seems to suggest that MSBuild.Sdk.SqlProj.BuildTSqlScript would be a good value 'scoped' to the MSBuild.Sdk.SqlProj SDK project. Would like to know if this is correct or not, in case I need to add custom capabilities to my own MSBuild.SDK.SystemWeb SDK.

[ErikEJ]

@CZEMacLeod Thanks, that was how I ended at my proposal

[drewnoakes]

@CZEMacLeod thanks for pointing that out. I have seen almost no adherence to that guidance (example), so take from that what you will. At the end of the day you just need a unique string for a capability, so choose whatever makes the most sense in your use case.

Consider adding both an MSBuild property and ProjectCapability to help consumers of your project identify its type in different contexts. A property is easier to test for than an item in MSBuild. A project capability is easier to test for in VS extensions.