Project capability proposal: [MSBuild.Sdk.SqlProj.BuildTSqlScript] about vsprojectsystem HOT 7 CLOSED

@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.

from vsprojectsystem.

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

from vsprojectsystem.

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

from vsprojectsystem.

Maybe a better name would be:

MSBuild.Sdk.SqlProj.BuildTSqlScript

from vsprojectsystem.

I commented on the original issue, suggesting that perhaps an MSBuild property would be a better fit for the use case rr-wfm/MSBuild.Sdk.SqlProj#341 (comment)

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

from vsprojectsystem.

@drewnoakes So just BuildTSqlScript as name is fine?

from vsprojectsystem.

@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.

from vsprojectsystem.