Visual Studio and .NET Framework Home
AssemblyInformationalVersion should not generate CS1607
5/1/2007 10:29:35 PM
User(s) can reproduce this bug
If you specify a non-version-number-like AssemblyInformationalVersion attribute on your assembly, then a warning like the following is generated:
warning CS1607: Assembly generation -- The version 'production test' specified for the 'product version' is not in the normal 'major.minor.build.revision' format
Given that this attribute is documented as being entirely for informational purposes and not used by the runtime, and is always expressed as a string (and eg. not parsed into a Version), this warning seems spurious.
Visual Studio 2005 (All Products and Editions) Service Pack 1
Windows XP Professional
Operating System Language
Steps to Reproduce
Create an assembly that contains the following line in its AssemblyInfo.cs:
The warning mentioned in the description is generated.
No warning should be generated.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 1/1/2012 at 3:54 AM
I'm now using VS 2010, and the issue is still there.
I would like to see a clean build with no warnings.
on 5/17/2011 at 10:48 AM
Still happens in VS2010 SP 1
on 9/17/2009 at 6:28 PM
Sorry that an update on this issue fell through the cracks!
After reactivating the bug, the issue was fixed on 9/8/2008 in our Visual Studio 2010 codebase and should no longer occur as of Visual Studio 2010 Beta 1. Unfortunately, the fix came too late to be included in Visual Studio 2008 SP1, which shipped on 8/11/2008, and we do not currently anticipate another Service Pack in which to patch Visual Studio 2008.
Visual C# Compiler
on 12/14/2008 at 7:25 PM
What's happening with this bug? Why is it marked as CLOSED with no comment, when its still an issue with the latest compiler?
This is now affecting us, as we need to have "Treat warnings as errors" turned on, but we need to use this attribute as a free-text field.
Where can we vote on this to have it fixed? I think its well overdue.
on 9/19/2008 at 3:02 PM
The problem isn't fixed in VS2008 SP1.
on 6/5/2008 at 3:00 AM
What do you mean by 'next version of Visual Studio'?
The problem is still there in VS2008. Will it be fixed in SP1?
on 12/7/2007 at 3:26 AM
Good catch! :)
You're right, there is no standard format for the non-binary Product Version resource. Given the examples provided on that page, compounded by the fact that you cannot use #pragma warning to disable this warning, I am reactivating this issue. We will consider removing this warning for the next version of Visual Studio.
Thanks for your quick response! (and sorry about the slow response on our part!)
Visual C# Compiler
on 12/7/2007 at 3:02 AM
So it is. I apologise for missing that before.
However as shown in http://msdn2.microsoft.com/en-us/library/aa381058.aspx, there is no mandated format for the ProductVersion string, and no tools should be trying to parse it. (Display it, yes. Parse, no. That's what the binary PRODUCTVERSION is for.) So the warning is still spurious.
Also, #pragma warning doesn't actually work on it, meaning that it can't even be disabled narrowly enough to prevent loss of useful warning cases.
on 12/7/2007 at 2:28 AM
The version text you put in AssemblyInformationalVersion ends up in the Win32 version resource as the Product Version. You can see this by right-clicking an assembly .EXE or .DLL with an AssemblyInformationalVersion attribute, choosing Properties, navigating to the Version table and selecting Product Version. Being as other external tools may attempt to parse this resource entry as a standard Windows version number, it is best practice to either leave this attribute out or supply it a version formatted in the standard manner.
Visual C# Compiler
on 5/4/2007 at 2:03 AM
Ok, I take that back -- I just noticed that C# 2005 does indeed support #pragma warning (though I'm positive earlier versions didn't).
I remain curious about your statement that it can be used to set the assembly's version number, though. Isn't that what the AssemblyVersion or AssemblyFileVersion attributes are for? Given that this is documented to be purely informational I think the developer should be free to put whatever free-form text they feel like in there and not have it try to get mysteriously interpreted by the compiler. (Although having said that, it might be useful if it was put into the Win32 version resource somewhere too. There also seem to be a few of those that don't have corresponding attributes.)
on 5/4/2007 at 1:52 AM
It's not all that harmless, since it's a persistent warning that hangs around forever. And since C# lacks the ability to disable specific warnings within a particular scope (like C++'s #pragma warning), there isn't a good way to remove it without potentially hiding other more serious warnings.
Some of us like to make clean builds, you know :)
on 5/3/2007 at 2:34 PM
Thanks for taking the time to report this issue. As it turns out, AssemblyInformationalVersion can be used to set the assembly's version number, that motivated the original issue of the warning. But as this page notes http://msdn2.microsoft.com/en-us/library/51ket42z.aspx, the warning is harmless. We will be changing the documentation to note the harmlessness of the warning in more obvious places. Sorry for any inconvenience this has caused.
C# Compiler Development Lead.
on 5/1/2007 at 10:55 PM
Thanks for your feedback. We have reproduced this bug on Win2003 SP2 and OrcasBeta1VSTS, and we are sending this bug to the appropriate group within the Visual Studio Product Team for triage and resolution. Thank you, Visual Studio Product Team.
on 5/1/2007 at 10:43 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com). Thank you, Visual Studio Product Team.
to post a workaround.
Please enter a workaround.
on 4/20/2010 at 11:50 AM
Really there is quite simple workaround (at least works for me:) ) in VS 2008
- open your project properties
- go to the Build page
- add 1607 to the Suppress warnings
and build your solution
You should see no warnings.
© 2014 Microsoft