Resource Naming DependentUpon Convention#4597
Conversation
rainersigwald
left a comment
rainersigwald
left a comment
There was a problem hiding this comment.
Some nits, but looks good.
Co-Authored-By: Rainer Sigwald <[email protected]>
|
cc @davkean |
| /// </summary> | ||
| public class CreateVisualBasicManifestResourceName : CreateManifestResourceName | ||
| { | ||
| public override string SourceFileExtension => ".vb"; |
There was a problem hiding this comment.
Is there an F# equivalent to this somewhere? cc @KevinRansom
There was a problem hiding this comment.
livarcocc
added
the
Approved to merge
|
Do we need any follow up validation from the WPF/WinForms team? Any value in having them trying out a private before merging? |
|
@livarcocc it certainly couldn't hurt, but I wouldn't think it's necessary. @rainersigwald may think otherwise |
|
I think several folks are on vacation, but worth looping in @merriemcgaw @dreddy-work @zsd4yr. |
|
Did you test this with an item that has a partial path as it's ItemSpec? /cc @Anipik |
|
Yep that appears to be it. Thanks for the pointer. For some reason my searching didn't find it. I should have looked at referenced issues. Thanks! |
5 participants
Description
In SDK projects and new project system, we have eliminated the need for DependentUpon to make the appropriate file nesting in the IDE tree. However, there is a place where the build actually uses DependentUpon to:
But people and features in VS rely on this and it has been a consistent source of feedback in moving to .NET Core 3.0. This opts into new behavior to use a convention instead of requiring explicit metadata.
Original issue: #4488
This change is dependent upon: dotnet/sdk#3533
Customer Impact
In a fairly common situation for projects that use resources, avoids the need to specify
DependentUponmetadata for each resource.Regression?
No
Risk
Low risk.
Test changes in this PR
Fixes #4488
Added new argument to CreateManifestResourceName:
UseDependentUponConvention