-
-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for NBGV_ThisAssemblyNamespace
property.
#911
Conversation
@AArnott How do you feel about the approach here? Also, how would you suggest I test this? I'm not really familiar with NBGV's test harness. |
I wonder about ThisAssemblyNamespace being null vs. an empty string. If the AssemblyVersionInfo task is called from Nerdbank.GitVersioning.targets, then what do users set in MSBuild properties to distinguish between those cases? |
Here it distinguishes null from "", but if ThisAssemblyNamespace is "", then I don't think the generated F# code will compile anyway:
Likewise C# here: Nerdbank.GitVersioning/src/Nerdbank.GitVersioning.Tasks/AssemblyVersionInfo.cs Lines 762 to 765 in adb0bcd
I think those null checks should all be !IsNullOrEmpty(ns), or alternatively map "" to null before any CodeGenerator is called. |
@KalleOlaviNiemitalo MSBuild does not distinguish between null or an empty string as property values, nor an unset value vs. a value set to an empty string. An MSBuild task property that is set to an msbuild property will never be null, although I believe it will be null if the .targets file doesn't set the task property at all. |
Well then the ?? operator in the F# case makes no sense at all. |
The PR looks ineffective for the other languages as well, since only F# emits a namespace. The other languages just no-op for the emit namespace instruction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexrp you can add the tests to this file. Please test all the languages. There is already a test for each language, so leave those alone I suppose but duplicate them with your optional property set.
Please make sure the task works properly given task inputs that are set to the empty string (indicating the msbuild property is not set).
Not sure I follow here. There's code to emit namespaces for all of them. It's just that the F# case is handled specially in |
@@ -119,7 +121,8 @@ public string BuildCode() | |||
this.generator.AddBlankLine(); | |||
this.generator.AddAnalysisSuppressions(); | |||
this.generator.AddBlankLine(); | |||
this.generator.EmitNamespaceIfRequired(this.RootNamespace ?? "AssemblyInfo"); | |||
this.generator.EmitNamespaceIfRequired(this.ThisAssemblyNamespace ?? this.RootNamespace ?? "AssemblyInfo"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is the conclusion that this should be changed to use string.IsNullOrEmpty()
for both of these properties?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, that would probably be appropriate.
No, I don't think so. The tests themselves prove that no namespace is emitted for C# or VB, but there is for F#. Issue #555 was originally filed because this class is always in the same global namespace for all projects. |
But that's expected, right? The PR makes it so that, for C#/VB, a namespace is only emitted if the project explicitly sets I could make it always emit a namespace, but I figured that might be a bad idea for compatibility reasons. |
Agreed, we don't want a namespace by default. But I'm pointing out that because we never wanted a namespace before, we never implemented emitting code for the namespace, except for F# which required it. If you look at |
Here (and similarly for VB): I put the code in those methods out of convenience since for C#/VB it requires opening and closing a namespace, unlike F#. (Also, I figured we shouldn't rely on file-scoped namespaces since people might be using older C# versions?) I could add a new pair of |
Certainly are. |
Ah, I missed that. I don't think we should have two separate methods for emitting namespaces. |
C# allows assembly attributes before For F# however, BuildCode calls EmitNamespaceIfRequired before GenerateAssemblyAttributes, i.e. the attributes come after the namespace declaration. Does F# allow attributes before the namespace? If not, that gets tricky to unify. It might be best to give the language-specific classes full control on the order of calls. |
Bummer. Ya to give the language-specific generator more freedom, let's just set a namespace property on the class, and the generator can pick it up when it wants to. |
OK, here's take 2, now with tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much better. Thank you. Just one small change please.
Thanks again. |
Closes #555