AssemblyInfo Updater does not update fully qualified attributes

FinalBuilder Bugs
1

This is another wrinkle to this issue. If one uses fully qualified paths rather than having using statements, the AssemblyInfo Updater appends unqualified attributes that fail. An example is shown below:

[assembly: System.Reflection.AssemblyVersion("1.0.0.0")]
[assembly: System.Reflection.AssemblyCompany("My Company, Inc.")]
[assembly: System.Runtime.CompilerServices.RuntimeCompatibility(WrapNonExceptionThrows=true)]
[assembly: System.Reflection.AssemblyProduct("ApplicationHandler")]
[assembly: System.Reflection.AssemblyCopyright("")]
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
[assembly: System.Reflection.AssemblyTitle("ApplicationHandler")]
[assembly: System.Reflection.AssemblyDescription("Simplifies manipulating Hwnd items.")]
[assembly: System.Reflection.AssemblyConfiguration("")]
[assembly: System.Runtime.CompilerServices.CompilationRelaxations(8)]
[assembly: System.Reflection.AssemblyTrademark("")]
[assembly: System.Runtime.InteropServices.ComVisible(false)]
[assembly: System.Runtime.InteropServices.Guid("beba9058-7a17-4079-81d8-f76f22da5260")]
[assembly: System.Reflection.AssemblyFileVersion("1.0.0.0")]
#region Assembly Information Added By FinalBuilder
[assembly: AssemblyFileVersion("1.6.1.1610")]
[assembly: AssemblyVersion("1.6.1.1610")]
#endregion

Note: Only one project of the 50+ in the solution was done this way so we are just changing it. However since the syntax is correct even if non-standard, it seems like the action should be able to handle it correctly. Using FB 8.0.0.2983.

2

I agree this is not great, will look into it.

FWIW, the only two attributes that the action actually has any knowledge of is those two it’s getting wrong! I guess you are updating those from a property set as that is the only time I could see this happening? If not then it’s just a case of fully qualifying them in the action.

3

This turned out to be harder to deal with than I would have thought. The way the action is structured, it has no way of knowing that the file has fully qualified versions of the attributes before it generates the new/updated entries from the property set. Changing this would be a major amount of work, so as a work around I added a new option to fully qualify those two attributes from the property set (defaults to false). Will be in the next update.