A strongly-named assembly is required.

There are instances when you are try to use a nuget package in  your project and you end up with the error "A strongly-named assembly is required.". 

This is because you have given strong name to your assembly however the nuget package isn't strongly-named. Some of the nuget package release the strong-named versioned but not all. 

If you are hit with this road block, you can add a nuget package "StrongNamer". This nuget package will take care of signing the other assemblies. 

Build Version Number in Azure DevOps

We migrated from TFS to Azure DevOps and hit with the road block to start the versioning from the same number where it left off in TFS.
Say TFS Last build number is : 1.0.0.91
then I want the next number in Azure to start with 1.0.0.92.

Here is how i cracked it.

Create a variable say V4 and set it's value to $[counter(92)].
and then you can use $(V4) in build version number. This variable is maintained per pipeline. and increment automatically any time a build is made.

There is another issue that you want to reset the 4th build number any time first 3 number changes. So you want your 4th Number relative to the first 3 version numbers.
For example,
your current number is 1.0.0.92
and you increment third number,
1.0.1.X, you don't want your X to be 93 next. you want it to start from 0. and same rule applies anytime you change other build number

Here is how you can change it.
Create 4 variables in build pipeline.
V1 => 1
V2 => 0
V3 => 0
V4 => $[counter(format('{0}.{1}.{2}',variables['V1'],variables['V2'],variables['V3']),0)]

Here V4 is defined as related to V1, V2 and V3. The value of the counter (V4) will be maintained per value of V1, V2 & V3 per pipeline. any time the the value of any V1, V2 & V3 changes, V4 will reset the counter to zero.

This will fix your problem of managing the build number for your builds.