How to automatically increment the assembly version number in C# .
NET6 no longer has AssemblyInfo.cs, as we all know
And i try the answer at
How to auto increment the version (eg. “1.0.*”) of a .NET Core project?
it doesn't work
Related
I've run into a rather interesting problem at work. We have a .NET Core application that we need to develop. Because it's spent so long in development, it's all written in .NET Core version 1.
Now we add support for Microsoft OpenID to it. The thing is, Microsoft OpenID doesn't work with .NET Core version 1, it needs .NET Core version 3.
At the same time, customers are expecting steady deliveries, so we can't risk breaking the old .NET Core version 1 application until we have a fully working version of it written in .NET Core version 3.
So what I did was to make a different project in the same source code folder, using .NET Core version 3, and add the exact same source code files to it. Not duplicates - the exact same files. I just needed to add a bunch of #if - #endif directives to get around differences between versions 1 and 3.
But then there's the thing that the .NET Core version 1 application needs a global.json file containing "version": "1.0.0-preview2-003121" in the "sdk" section, otherwise Visual Studio will try to compile it in .NET Core version 3, which will fail. This, however, will break the new version, which needs to use sdk version "3.1.300".
So in effect I would need to have two different "version" lines in the same "sdk" section in the same global.json file, with some kind of #if - #endif directive for conditional compilation. But I don't think global.json supports that.
How can I resolve this problem? Or is there any better way I haven't thought of?
I know that there are two GACs will be available on a system where latest .NET framework is installed.
i.e. "C:\Windows\assembly" for framework lower than 3.5, and "C:\Windows\Microsoft.NET\assembly\GAC_MSIL" for 4.0 and above.
Now, I have two questions:
First question is, I've a C#.NET assembly developed in frawework 4.5 and i have to add a reference to Microsoft.Office.Interop.InfoPath.Xml.dll.
I'm not finding this reference in the latest GAC, but it is there in the old one. So can I add from the old GAC?
Second question : If I install a latest version of Office, this reference also get migrated to another version. So unless I re-refer this dll in my project, my assembly cannot load the mentioned dll as it is checking for exact version number. Is there a generic solution for this, so that I need not change the reference and rebuild my application?
Remove the references to the GAC and use the assemblies from the file system. Set CopyLocal = TRUE;
You may need more than the one Assembly, an article here - InfoPath Interop describes the assemblies required.
The InfoPath primary interop assemblies can be downloaded here: http://msdn.microsoft.com/en-us/library/15s06t57.aspx
Using VisualStudio 2013 I've successfuly compiled the latest version of dnlib which is part of the ConfuserEx and de4dot projects, the dnlib project by default targets .NET Framework 2.0 so it should be compatible to reference it in other projects that targets a greater version but when I reference the resulting dnlib.dll in a new project that targets a .NET framework greater than 3.0 the project can't compile.
There is any compiling error information just a VisualStudio messagebox that says:
There were build errors. Would you like to continue and run the last
successful build?
I've tried the dnlib.dll in a (new, empty) WinForms project using both the debug and the release version of dnlib.dll, I've tried targeting FW 3.5, 4.0, 4.5 and 4.5.1 but the project has been compiled successfuly only targeting FW 2.0 and 3.0.
By the other hand, I'm totally able to navigate through the library members and instance the classes inside and all that, but no way to compile a project with that referenced dnlib.dll.
I think that if the default FW targeting in the dnlib project is 2.0 should be for a good reason 'cause it touchs external assemblies and that, so I'm not sure to try to solve this issue by increasing the FW targeting in the dnlib project, but anyways I've tried to increase it to 4.0 to see what hapens and I get a lot of compiler errors about type defs in mscorlib.dll.
I'm missing something?
How I can solve this problem to be able to compile a project that targets FW4.0 with the dnlib.dll that targets FW2.0 referenced?
Ok, fiddling around, I could get some Warnings but not errors. As per MSDN, ExtensionAttribute came into being with Net 3.0 and HandleProcessCorruptedStateExceptionsAttribute with NET 4.0. So, in order to make the NET 2.0 code compatible with 4.0 projects, it provides the missing Attributes. The warnings are just that they are multiply defined, and since they are just Attributes, I don't think it matters.
Rather than comment them out, there are 2 easy ways to get rid of the Warnings.
Method 1 (better, I think): Create solutions for Net 2.0 and 4.0 builds.
Open the basic Net 2.0 solution. Select the Solution (dnlib) in Solution Explorer. On the File menu pick Save dnlib.sln As and use dnlib20.sln as the file name. This is your NET 2.0 FrameWork Solution.
Do Save As again, this time to dblib40.sln. This will be your Net 4.0 Framwwork solution in a moment. Switch both the console test project and dnlib library projects to Net 4.0 Target platform. Then, in Solution Explorer, exclude the last 2 files from the solution: HandleProcessCorruptedStateExceptionsAttribute.cs and ExtensionAttribute.cs. Save it, clean and build, and you should be good.
You don't need these 2 files because NET has them defined (which is the warning); they are only meant for 2.0 projects/solutions.
Note: You can also set it up so that the solutions compile to their own folders, so you dont get them confused. On the Build Tab, next output add a folder(..\Debug\bin\Net20 and ..\Debug\bin\Net40). You'll have to change/update for both Debug and Release versions.
Method 2: Define some conditional compiler constants.
Create dblib20.sln and dblib40.sln solutions as above (unless you dont want to even use 2.0). Be sure to set the Framework to NET 4 in the 4.0 solution.
In the Net 2.0 dnlib project file, go to Project Properties --> Build --> General add the conditional compile symbol NET20. Now, in HandleProcessCorruptedStateExceptionsAttribute.cs wrap the code there in a #if:
#if NET20
using System;
#pragma warning disable 1591 // XML doc warning
namespace System.Runtime.ExceptionServices {
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
sealed class HandleProcessCorruptedStateExceptionsAttribute : Attribute {
}
}
#endif
In ExtensionAttribute.cs, do the same thing. Then Clean and Rebuild, and all should be well. Since the symbol is only defined in the NET20 solution, those classes will only be compiled when you use/open the Net 2.0 solution. If you download another update, you will have to redo this unless they provide a NET 4.0 solution file.
AFAIK, there still are not any built in FrameWork constants.
Finally, when those warnings are cleared away, there are 5 compare warnings, but from the looks of it, those can be ignored (the code seems to be doing what it wants).
This worked for me:
Change dnlib project's target version to .NET 4.0 Framework Client Profile.
Change the Example project target version to .NET 4.0 Framework Client Profile.
Remove/comment out ExtensionAttribute in ExtensionAttribute.cs in dnlib
Remove/comment out HandleProcessCorruptedStateExceptionsAttribute in dnlib
I then compiled and got no errors.
I used Visual Studio 2012.
I compiled a Java application to a C# dll with IKVM. I tried to use this dll in a C# project which uses .Net Framework 2.0 but failed since the converted dlls framework obviously is higher. I looked through the arguments of the IKVM compiler but didn't find anything regarding the framework.
My question now is:
Am I able to specify the framework version of the compiled DLL/EXE with IKVM? If so, how?
Thanks in advance.
The current version of IKVM 7.1 is build with the framework 2.0. If you create a dll with IKVMC then it use by default the framework 2.0. Another thing is if you build IKVM self.
If you want compile a dll for a higher framework as 2.0 then you need to use the command line parameter:
-nostdlib
And you need to set the all needed references (like mscorlib.dll) to the target framework with the command line parameter:
-r:<file name>
According to my search through all the IKVM versions the IKVM 0.38.0.2 version and later all contain IKVM binaries built with framework 3.5.
0.36.0.11 was the last version depending on 2.0. That version only supports Java 6 and is way too old anyway.
I have a project which references another project's dll. They both were in .net framework 2.0.
So upgraded both to 3.5, but when I go to reference for second project(the one referencing the first project) it still says on properties runtime version 2.0, even though I deleted the reference and readded.
How would I determine if the referenced dll is the upgraded one, before deploying to server where it has version 2.0?
I don't want to delete all files in server and deploy, after upgrading do I need to check the config files are referencing same dlls and deploy published files or it needs replacing all together?
.Net 3.5 and .Net 2 both run on version 2 of the CLR, so the runtime version of the 'old' and 'upgraded' assemblies will not change.
As for finding out whether it is 'upgraded', I would recommend using ILDASM to see which version of mscorlib is referenced.
However, the answers to this SO question provide a few alternatives.
You can easily check which version the assembly is build against by opening it up in Reflector (or another decompiler).
The CLR for .NET 3.0 and .NET 3.5 is the same CLR from .NET 2.0.
Hence the best way to check, if your assemblies are upgraded or not, is to use Assembly version. Do maintain assembly version and build version in AssemblyInfo.cs while building the assembly.
Having a strong named assembly is the best way to check.