MSBuild.Sdk.SqlProj
MSBuild.Sdk.SqlProj copied to clipboard
rr-wfm
Feature Request: Automatically add a MSBuild property (IsDatabaseProject) via the SDK
I have run into a scenario where it would be very handy to know if a given project is a "Database Project" or not. Similar to what the Test SDK does with adding the "IsTestProject" property it would be nice if this project type SDK could do the same and add one named "IsDatabaseProject".
I've looked at what is currently present for an interim solution for anything I could inspect and use to evaluate, but I'd much rather have a purpose-built approach to leverage.
For context, one of the reasons for this request is that the default project created by the templates uses .CSPROJ and no longer has the convention of using .SQLPROJ which I had initially considered using. I was surprised by that change, as I would have expected to still be indicating the specialized nature of these database projects via that original naming.
Since anyone using the template to generate their project would have to go and manually alter the file suffix, I decided a property would be better since it wouldn't be relying on naming conventions.
I have experimented with renaming the projects to .SQLPROJ and it appears to work, but I did have some hiccups and build failures at times, but I haven't quite pinned down why it failed when it was failing.
Would there be any issues with renaming the projects to follow the old file suffix naming convention?
@bhehe Thank you for your feedback.
To be honest there's a reason we chose to adopt .csproj instead of .sqlproj. I believe the latter triggers certain behaviours within Visual Studio, which are not compatible with this project. That being said I've never really tried it, so I'm not sure how big of an issue it would be. It would be interesting to know what kind of issues you run into with that setup though.
Setting an IsDatabaseProject property by default would be as simple as modifying the Sdk.props file and include it there. I'm not against that so feel free to submit a PR for that. Please be aware though that I'll be away on holiday starting tomorrow and the whole of next week, so it will probably take some time before an update is shipped.
@jmezach Thanks for the context, I wasn't sure if there were any behavioral aspects tied to the filename suffix. Not surprised there is so that makes sense.
So far it appears to work for me with the renaming, but I just wrote-up another separate issue where I am seeing some odd behaviors that only manifest when running in an Azure build pipeline. @ https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/issues/342
I don't believe it's related to the renaming, but I can't rule it out either.
https://github.com/microsoft/VSProjectSystem/blob/master/doc/overview/about_project_capabilities.md
@jmezach I could also use this, but wonder if a capability is better. I need to get hold of it from another VS extension and can do that easily with a capability.
Capabilities are generally intended for enabling features in VS. For example, if you ship an extension that has a MEF component that implements some service within VS that should only apply to certain projects or in certain contexts, you can filter that based on the project's capabilities.
It doesn't really sound like the goal here was to achieve that. There's no VSIX in this repo that I can see. Using an MSBuild property is likely a better fit for (my understanding of) the original use case here.
In my case, I had a scenario where I needed to skip over the 'database projects' and rather than maintain some list/manifest I was simply wanting to use the metadata of the project properties to get something I could use as a marker/fingerprint to ID those projects which were of this type.
After reviewing I think (?) there is something specific in there that would identify these project types but I've since taken a different path on things and this isn't as much of a pressing issue. I can't even get these project types to load & parse so I can access the properties - but it works locally but fails in Azure pipelines. I had a separate issue created for that.
IMO there's still value in something simple that could indicate "this is a database project" generically as a trait. And then if someone needs to know specifically if it's this newer SDK-style database project - that would be good as well but I'd expect they should be able to inspect/probe the sdk type itself to get that.
Until I can get the project parsing/failing in the build pipeline deal behind me, I can't even use the properties for these projects.
For reference, the issue I was having is closed but I was never able to get a workaround. Sounds like others were in the same shoes. I never pinned down and rhyme or reason for why it would work in my local Nuke build -vs- failing when the very same build was ran in an Azure build pipeline.
https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/issues/342
@drewnoakes actually the PR May not solve this issue, but my need is actually for a vsix for project trait detection.
@jmezach I will revert to the shorter name and remove the link to this issue.
@jmezach @bhehe As far as I can tell this has always been solved !?
https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/blob/master/src/MSBuild.Sdk.SqlProj/Sdk/Sdk.props#L9