Wpf: WPF attributes coming to csproj or remain in AssemblyInfo?

[MV10]

Now that .NET Core (or perhaps more correctly stated, MSBUILD?) is supposed use a hodgepodge of new csproj XML tags to create the assembly attributes we used to declare in AssemblyInfo.cs, what's the plan for WPF when it comes to things like System.Windows.ThemeInfo or the XML namespace attributes from System.Windows.Markup? Right now I'm having to create a my own Properties folder and AssemblyInfo.cs.

Assuming WPF will follow the pattern of Even More Tags, will they be documented with the rest of csproj, or stashed away somewhere WPF-specific? (It looks like the current csproj docs are already missing a lot of tags, judging from the open issues list.)

Or is it all still too early to say for sure?

[wjk]

IMHO, the WPF-specific attributes might not be the best fit for project-based properties. ThemeInfo may be a good one, if the parameters are the same/similar across many different projects, but the System.Windows.Markup attributes would not work well in the csproj file. This is because you can have more than one attribute instance applied to the assembly (necessitating an MSBuild item instead of a property, which is more complex), and because there are multiple required parameters (which does not map to MSBuild semantics very well; it can be done, but it will be clunky).

However, that being said, there is no rule that says assembly attributes _have_ to be placed in Properties\AssemblyInfo.cs; they can be safely placed in any C# file in your project, as long as they come before any other syntax construct other than using statements (a C# compiler requirement). Hope this helps!

[dotMorten]

I agree with @wjk. Just because csproj generates some assembly-level attributes, Assembly level attributes are used for a wide variety of scenarios, and csproj isn't meant to replace them all. For instance consider that if you add custom controls to your wpf library you have to add more of these attributes, but if you only have user controls, you'd never add those.

Having said that, I think dotnet new wpf should generate a project template with an assemblyinfo file with some of these attributes.

[MV10]

@dotMorten Pretty much what I was thinking, too.

[vatsan-madhavan]

@dotMorten, which attributes would you recommend for dotnet new WPF to generate by default?

[dotMorten]

I just think the project template should declare the themeinfo in a code file (but not "secretly" auto-generate it the way it does assembly versions etc:):

[assembly: ThemeInfo(
    ResourceDictionaryLocation.None, //where theme specific resource dictionaries are located
                                     //(used if a resource is not found in the page,
                                     // or application resource dictionaries)
    ResourceDictionaryLocation.SourceAssembly //where the generic resource dictionary is located
                                              //(used if a resource is not found in the page,
                                              // app, or any theme specific resource dictionaries)
)]

[MV10]

45 and #96 are somewhat related. I actually started thinking about this when I needed to create a file for namespace attributes. I would also say that the template should include a commented-out example of XmlnsPrefix and XmlnsDefinition as guidance.

[dotMorten]

@mv10 why is that different for .net core? We never had it in the current wpf framework templates.
I don't like all the commented out pieces of code. Templates should generate clean not dead code

[dotMorten]

Also if I had to be pedantic none of these things should be in an AssemblyInfo.cs file, but in something named for it's xaml specific attributes.
It also keeps the clear distinction that assembly info metadata is auto generated, and this is something different

[MV10]

From where I sit there isn't anything but .NET Core. 😀

The reason I suggested it is "as guidance" -- but just my opinion since I see a lot of people trying to figure out how that works (StackOverflow etc). Help people "fall into the pit of success" as the saying goes.

Definitely agree about naming it something else, though.