Is there any way to use a custom format for assembly versions, when building them with MSBuild?
For example, we tried to use a version like "0.16.10r2.10717" But we got this error:
error emitting 'system.reflection.assemblyversionattribute' -- The version specified '0.16.10r2.10717' is invalid.
I searched around the web, but seems no one asked for a solution of this. Is it possible?
We use Microsoft Visual Studio 2010, and FinalBuilder 7 for building our project.
AssemblyVersion and AssemblyFileVersion both must be composed of up to four integers, period-separated, each of which is no larger than 65534 (UInt16.MaxValue-1). Any of the following are valid (C# syntax):
[assembly: AssemblyVersion("1.2.3.4")]
// Let the compiler generate the build and/or revision numbers
[assembly: AssemblyVersion("1.2.3.*")]
[assembly: AssemblyVersion("1.2.*")]
There is another attribute, AssemblyInformationalVersion, that accepts a string as the version; it can be used when you want to use more complicated strings (especially when including a commit ID from a DVCS).
// Use complex version number
[assembly: AssemblyInformationalVersion("0.16.10r2.10717")]
// Include Git commit ID
[assembly: AssemblyInformationalVersion("1.2b1-g39d1c0f")]
Briefly, the difference between these attributes is:
AssemblyVersion: This is used as the CLR version of the assembly. When the assembly has a strong-name, this is the version that is validated against.
AssemblyFileVersion: This is the Win32 file version resource, and is displayed in the assembly's properties in Windows Explorer.
AssemblyInformationalVersion: This is accessible at runtime via the Application.ProductVersion property. It is also used in the Application.UserAppDataDirectory path.
Related
Using Visual Studio 2019 to build a C# Class Library. The assembly has an AssemblyInfo.cs file with these attributes:
[assembly: AssemblyVersion("8.0.*")]
[assembly: AssemblyFileVersion("8.0.0.0")]
In .csproj, the Deterministic tag was set to false, the project was then reloaded and rebuilt. Right-click the assembly and Properties > Details shows:
File version = 8.0.0.0
Product version = 8.0.0.0
What am I doing wrong?
Ideally File version would have the format 8.0.BUILD.REVISION with BUILD the days since 2000-01-01 and REVISION half the seconds since 00:00. And Product version would be just 8.0.0.0. Is this possible?
Update
After some experimentation, commenting out AssemblyFileVersion:
[assembly: AssemblyVersion("8.0.*")]
//[assembly: AssemblyFileVersion("8.0.0.0")]
gives part of the answer. Now Properties > Details shows:
File version = 8.0.7710.25829
Product version = 8.0.7710.25829
Progress! But is there a way to have an auto-generated BUILD and REVISION for File version but to have a fixed Product version?
The answer from #MarkBenningfield did not work for me, but prompted me to experiment. Here's the solution that gave the result I needed. In AssemblyInfo.cs, set the lines to:
[assembly: AssemblyVersion("8.0.*")]
[assembly: AssemblyInformationalVersion("8.0.0.0")]
(and set Deterministic to "false" in the .csproj file).
Now the assembly builds with auto-generated BUILD and REVISION for File version, while displaying the Product version with my fixed string.
Visual Studio gives you the tags AssemblyVersion and AssemblyFileVersion by default for new projects. You need to swap AssemblyFileVersion for AssemblyInformationalVersion.
You've got it turned around. Use
[assembly: AssemblyVersion("8.0.0.0")]
[assembly: AssemblyFileVersion("8.0.*")] // older versions of VS use full asterisks ("8.0.*.*")
This will give you a fixed version for the assembly, and let you track build increments with the file version.
I am trying to build Xamarin Android binding libraries for two different RFID hand held scanner SDKs (from two different companies), and then reference them in a Xamarin.Android project. So the end goal is to have one application that can run on Device A or Device B and depending on the device manufacturer it will use a different implementation of a "scanner" interface. If I try to reference both of the resulting dlls from the Xamarin.Android project, then I get the following error:
Program type already present: com.hsm.barcode.DecodeOptions
Looking in the jars using JD-GUI as suggested in the Microsoft Docs I can see the problem is that both of the jars have a com.hsm.barcode package:
What is the best way to workaround this issue?
Note that if I use only one of the dlls then I have no issues.
What I have tried:
Using a single Xamarin Android binding library project for both jars - this gave exactly the same result
Renaming all of the classes in the jar to eliminate duplicate class names like this: <attr path="/api/package[#name='com.hsm.barcode']/class[#name='DecodeOptions']" name="name">DecodeOptions2</attr>. When I do this, in reflector I can see that the class name has indeed changed, but I still get the build error when building the Xamarin.Android project
Renaming the namespace in one of the projects: <attr path="/api/package[#name='com.hsm.barcode']" name="name">com.hsm.barcode2</attr>. Again, I can see the updated namespace in reflector but still I get the same "Program type already present" error when building the Xamarin.Android project
Similarly I have tried removing both the namespace and the duplicate classes using remove-node but seen similar results
This leads me to believe that this isn't necessarily an issue with the binding process but rather a more Android related problem. I have found some similar Android questions where people mention that you can use exclude module in gradle to remove dependencies [1] [2], but a) there seems to be no concrete answer that this is the right approach in this case and b) as I have been able to find gradle is not a tool that is used as part of the Xamarin/Visual Studio process.
My final desperate attempt to get something working was to unzip one of the jar files, remove all the .class files that are causing issues, then rezip and use this in the Android binding library and then reference this dll in my Xamarin.Android project. This seems to work (the project builds and runs) but I'm not sure it is the correct/safest/most stable solution.
To summarize, the question is: if you have two jars with duplicated namespaces/packages and you want to use both of these Jars in a Xamarin.Android project how can you avoid the resulting Program type already present: com.hsm.barcode.DecodeOptions error message.
Where to define this command in csproj file?
bin\Debug\net47\MyApp.exe
I m using .net core 2.0.0 SDK. I m not getting RunCommand in Intellisense. Also while building my solution, I have 7 projects and main project is of type console application and its Output Type is EXE. Solution gets built successfully. While I press F5 it gives me MessageBox containing message like "Unable to run your project. The RunCommand is not defined."
How to solve this?
This is typically set by the SDK. Most likely you are targeting netstandard2.0 (was it a Class Library project that you later added a Main() to?). Try targeting the specific runtime+version - in your case netcoreapp2.0 or net47 - instead.
If you want to build both Core and Full Framework you can specify multiple target frameworks by separating them with a semicolon and changing the TargetFramework tag name to plural (TargetFrameworks):
<TargetFrameworks>net47;netcoreapp2.0</TargetFrameworks>
Alternatively, you should be able to specify a <RunCommand> inside <PropertyGroup> in your .csproj file. FWIW I can't seem to get anything to show up in Intellisense except the generic <PropertyName> and anything I've already added to the list.
An example would be:
<RunCommand>bin\$(Configuration)\$(TargetFramework)\$(AssemblyName).exe</RunCommand>
In the WinPhone project of a VS 2015 v2 cross platform solution with Xamarin.Forms v2.2.0.13, two versions of ExceptionStringTable.resx are generated in the 'System Xaml/en-US' and the 'WindowsBase/en-US' folders with different contents. At the moment a dependent assembly, XCRRequiresAttribNotFound, found in both files, has conflicting values during build, one having an extra 'a' in the string. Since they are Build generated, why are they not the same value?
Comparison of Values
It looks like you have Platform specific assemblies referenced in your PCL. In this case, it seems that you have a reference to WindowsBase.dll somehow within your PCL. (This could be inside something like PresentationCore.dll or similar).
I would recommend that you do the following:
Compare this against a File -> New Forms Project (PCL) - To see what default references are within Forms by default in the PCL.
Replace any old desktop/platform specific code with the Forms APIs instead - https://developer.xamarin.com/api/root/Xamarin.Forms/
Profit!
If you have any further problems, I would recommend using grep on certain strings like WindowsBase to see exactly where this is coming from. In this case it's a reference to PresentationCore.dll
We upgraded our .net 3.5 projects (c#) to .net 4.0. When you look at the project file there are two tags that I'm trying to make sense out of:
<RequiredTargetFramework>3.5</RequiredTargetFramework>
<TargetFrameworkVersion>4.0</TargetFrameworkVersion>
Why are there two seemingly similar tags with different values?
The <RequiredTargetFramework> element was already present in your 3.5 project. It's associated with the assembly <Reference> and only present on assemblies that are not available in .NET 2.0
I don't buy much stock in the single mention of it in MSDN, I don't see how batch building has anything to do assembly references. Nor is it used in any of the 3.5 MSBuild .target files. I think the IDE simply uses it to put the warning icon next to the reference in the References node when you change the Target Framework to a version less than what's needed to support the assembly.
There are other elements like this in a project file that don't affect MSBuild but have an effect in the IDE. Like <SubType> and <DependentUpon> in the <Compile> element.
Have you found this one link? link text. TargetFrameworkversion is easy, that's the one you can change in the project properties to say which framework to build against. The article says that RequiredTargetFramework is used to batch items (but it's still not clear on it' real purpose other than it's not used a lot)
batches the Reference items by their RequiredTargetFramework metadata. The output of the target looks like this:
Reference: 3.5;3.5
Reference: 4.0
Target batching is seldom used in real builds. Task batching is more common. For more information, see MSBuild Batching.