What does the star mean in the PackageReference in C#?
E.g. here:
<PackageReference Include="MyApp.Misc.Utils" Version="3.0.*" />
Does it mean that as soon as there is an upgrade in the least significant version of the MyApp.Misc.Utils, that update will reach the project which references the MyApp.Misc.Utils?
I.e. if the current used version of the MyApp.Misc.Utils is 3.0.5 and I release a new version of the MyApp.Misc.Utils to the registry and that version number is 3.0.6, then the MyApp.Misc.Utils dependency will be automatically updated to the 3.0.6. Is it correct?
Related
I have a C# .NET Framework project which I sign using a .pfx file on my local system. In the .csproj file the following properties are set:
<PropertyGroup>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile>keyfile.pfx</AssemblyOriginatorKeyFile>
</PropertyGroup>
This file is part of an open source project. I'm trying to create a pipeline which runs on certain commits. When I commit something, the original *.pfx can be installed using the password which is stored as a GitHub secret. The problem is that when forked repos make a pull request, the pipeline fails, because the GitHub secrets are not available to them.
Long story short, I found out that I can use public signing for this purpose. However, when I try to build my project using
msbuild src\TcBlackCore\TcBlackCore.csproj -t:Rebuild -p:DelaySign=false -p:PublicSign=true -p:Configuration=Release -p:Platform=AnyCPU -p:TreatWarningsAsErrors=true
I get the following error:
CS7102: Compilation options 'PublicSign' and 'CryptoKeyContainer' can't both be specified at the same time
I couldn't find any information on this error code except for one GitHub issue which mentions:
ERR_MutuallyExclusiveOptions CS7102
What are the mutually exclusive options here? The DelaySign should be set to the docs. And what should I do to get the public signing to work such that forked repos can be build?
> msbuild -version
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
The problem with public sign is that while the compiler applies a public key, is doesn't actually signs the assembly. It is like a 'mark' on the assembly.
In your case, you cannot use both CryptoKeYContainer and PublicSign at the same time because they are doing almost identical things, thus the compiler prompts the error.
for your purpose I would recommend using the DelaySign - as Microsoft docs states:
Use DelaySign - If you want a fully signed assembly. Use DelaySign
if you only want to place the public key in the assembly
For reference the tag is:
<DelaySign>true</DelaySign>
In my project.csproj file I have the following:
<PackageReference Include="System.Text.Encodings.Web" Version="5.0.1" />
However, my other dependencies pull in a lower version of the package as their dependencies. For example in my project.assets.json I see (18 total instances that pull version 4.5.0):
"Microsoft.AspNetCore.Http.Abstractions/2.2.0": {
"type": "package",
"dependencies": {
"Microsoft.AspNetCore.Http.Features": "2.2.0",
"System.Text.Encodings.Web": "4.5.0" // <-- the problem
},
How can I enforce a minimum version for these dependencies? To be more specific, any version above 4.5.1 would work to fulfill my needs for compliance.
I've found out that if you add the ProjectReference, that might actually solve the problem. Here is a good read:
https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution
After adding the ProjectReference, the project.assets.json still had the 4.5.0 as dependency but it only pulled in the ProjectReference version, which was 5.0.1 in this case.
In this video from MSDN at the 3:34 second mark, the presenter shows how to append the Build ID to a nuget's version. In the MSBuild arguments, he specifies:
/t:pack /p:PackageVersion=1.0.$(Build.BuildId)
So, when the project is built by VSTS, the nuget assembly's revision number is using the build id.
I would like to do something similar. Instead of hard coding the 1.0 in the build definition, I'd like to retrieve that from .csproj file. I am using the new .csproj file which stores nuget information.
For example, I'd like to specify in the csproj:
<Version>0.0.1-beta</Version>
Then, VSTS would append the BuildID and generate the assembly version as 0.0.0.1-beta.49 (49 being the build id)
I ended up doing the opposite of what Shayki Abramczyk suggested.
I use a task called "Variables Task Pack". It can be found here (and is free at the time of this answer): https://marketplace.visualstudio.com/items?itemName=YodLabs.VariableTasks#qna
Using this task, I set two variable: $(BuildId) and $(ReleaseType). See the settings snapshots at the end of the answer.
Then, in my CSPROJ project file, I modified the nuget version to use the two environment variables. Here's a clip of the project file:
<PropertyGroup>
<Version>0.0.0.0$(BuildId)$(ReleaseType)</Version>
<FileVersion>0.0.0.0$(BuildId)$(ReleaseType)</FileVersion>
...
</PropertyGroup>
IMPORTANT: Notice the extra 0 in front of $(BuildId). I had to add that in order to build locally. Without it, the build failed with an incorrect version format error.
Now, after building, I get the buildid as my revision number and release type appended.
Here are the screen shots showing configuration of both variables.
You can create a Power Shell script that retrieves the version from csproj file, then add the version to a new environment variable with this command: Set-VstsTaskVariable
For Example:
$csprojId = $retrivedIdfromTheFile
Set-VstsTaskVariable -Name "CSPROJ_ID" -Value $csprojId
Now you can use the CSPROJ_ID variable on the MSBuild arguments:
/p:PackageVersion=$(CSPROJ_ID).$(Build.BuildId)
I have a purchased license of the DLLs (6.9.4.10) and my *.csproj contains this:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.1.0"/>
...
<PackageReference Include="System.IO.Packaging" Version="4.5.0"/>
<PackageReference Include="System.Text.Encoding.CodePages" Version="4.5.0"/>
<PackageReference Include="ZKWeb.System.Drawing" Version="4.0.0"/>
</ItemGroup>
...
<ItemGroup>
<Reference Include="SautinSoft.PdfFocus">
<HintPath>..\PDF Focus .Net Full (6.9.4.10)\DLLs\Net Core 2.0\SautinSoft.PdfFocus.dll</HintPath>
</Reference>
</ItemGroup>
I am trying to convert a PDF into a DOCX-file (which worked in .NET 4.5).
This is the relevant part of the code:
....
SautinSoft.PdfFocus f = new SautinSoft.PdfFocus();
f.Serial = Settings.GetAppSetting("PdfFocusSerial", "**MySerial**");
f.OpenPdf(buffer);
if (f.PageCount > 0)
{
f.WordOptions.Format = SautinSoft.PdfFocus.CWordOptions.eWordDocument.Docx;
var result = f.ToWord(); //f.Exception set after this
...
}
...
I've checked that the same buffer is sent in as in the old code, but the output differs by some bytes. And I get an Exception set in f.Exception, which is:
{System.Collections.Generic.KeyNotFoundException:
The given key '0' was not present in the dictionary. ...
When I try to open the newly created *.docx-file, Word says it's damaged. After clicking through some dialogs it can still open the file.
Anyone have any ideas?
Is this a known bug for this library in .Net Core 2.1? (Only 2.0 is mentioned on their website)
I've also tried the free version published on NuGet with the same results.
EDIT
This was indeed a bug in the .NET Core specific version. They have fixed this in version 6.9.6.29.
My Name is Dmitry and I work in SautinSoft.
Thank you for your issue. You are right. We have some problems with PDF Focus.Net and Net Core 2.1
Our developers try to fix this issue. We have found where is a bug (resources/fonts) and I hope, that we will prepare a new version very quickly.
I'll inform you.
If you want to use "RTF to HTML" for Net Core 2.X-6.X please add these references in your project:
System.Drawing.Common, 4.7.0 or up.
System.IO.Packaging, 4.4.0 or up.
System.Text.Encoding.CodePages, 4.5.0 or up.
System.Xml.XPath.XmlDocument, 4.3.0 or up.
But If it will be Net Core 7.X for LinuxOS - it doesn't work, because the System.Drawing.Common NuGet package is now attributed as a Windows-specific library. The platform analyzer emits warning at compile time when compiling for non-Windows operating systems.
I am trying to change ServiceStack in my service from 3.9.43 to 4.0.9.
I had to change several things in my code and mostly followed the release notes for this.
There were a couple of weird things for me, like not finding anything to replace ServiceStack.WebHost.Endpoints or AppHostHttpListenerLongRunningBase but I could check those things after and was able to make my code to compile.
The problem is that when I run my code I get this exception in the very begining and it just kills the service:
Method 'ExecuteMessage' in type 'ServiceStack.Host.ServiceController' from assembly 'ServiceStack, Version=4.0.9.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
I get this when hitting the base:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ServiceStack;
using ServiceStack.Text;
//using ServiceStack.WebHost.Endpoints;
using ServiceStack.Web;
namespace ThisService {
public class AppHost : AppHostHttpListenerPoolBase { //AppHostHttpListenerLongRunningBase {
public AppHost(int wthreadMax)
: base("This Service " + VcsInfo.ChangesetId, wthreadMax, typeof(ThisService).Assembly) {
}
...
I am referencing in my project:
ServiceStack (4.0.9.0);
ServiceStack.Client;
ServiceStack.Common;
ServiceStack.Interfaces;
ServiceStack.Text
I am sure I am doing something wrong changing to version 4.* and am lost with what is trying to call the Execute Message since I think removed everything from the previous version. Any suggestion to where I should be looking to?
By the way, this a simple service: get json -> math + stuff -> return json.
I want to find out if a bug I found the version 3.9.43 still happens in version 4.0.9 (can't find anything specific about that bug but I believe one fix there is related) to see if I should actually re-factor my code for this version.
Update in v4.10
This should now be resolved in ServiceStack v4.10 where now all NuGet packages specify a minimum version for all dependencies matching the current version. This will force NuGet to pull down the latest packages instead of the oldest matching ones.
NuGet seems to have the weird behavior that it will pull in the lowest dependencies when you install a package, so if you install the latest version of ServiceStack, e.g:
PM> Install-Package ServiceStack -Version 4.0.9
It will pull in the lowest matching dependenices, e.g:
<package id="ServiceStack.Client" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Common" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Interfaces" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Text" version="4.0.3" targetFramework="net45" />
Which is an unexpected surprise. Unfortunately ServiceStack assumes that it's always working with the latest dependencies with the same version it was built with.
So after installing ServiceStack you will need to update all your packages which will bring them in-line with the latest versions, which you can easily do in the Updates tab in the NuGet UI, or in the NuGet Package Console Manager with:
PM> Update-Package
Manually remove any assembly redirects
Installing the previous v4.02 of ServiceStack (now removed) created new assembly redirects for ServiceStack.Interfaces in the Web.config which you should also manually remove if they exist. These now shouldn't be created for new projects.
I had the same problem as well. Therefore I tried installing an older v4 version from Nuget and managed to make it work.
Using Scott's example I can get this to work correctly if I install 4.0.4:
install-package servicestack -Version 4.0.4
If I use version 4.0.5 then it runs but the example web page reports
Method not found: 'Void ServiceStack.Web.IResponse.set_Dto(System.Object)
If I use version 4.0.6 or above then I get the error reported by RGPT.
So, for now it may be a case of using the 4.0.4 version until someone with more knowledge than me replies with a better answer. I've only just starting using ServiceStack today so I don't know much yet ;)
Update: I don't have high enough ServiceStack reputation to post a comment so felt best to edit my original post. The answer below by mythz had the key bit of information. Immediately update your nuget packages after installing and then check the web/config / app.config to see if any dependentAssembly bindingRedirects are hanging around - if so then remove them and away you go :)
I've had a similar problem as well. I followed the upgrade path, first via the Beta channel before upgrading to the offical channel. What I soon realised was that the Beta libraries had version numbers greater than the official channel.
NuGet will check for a more up-to-date version locally first, before pulling in the libraries remotely. Of course, it will pull in ServiceStack v4.0.x from the official channel, but all the dependencies will come from the already downloaded Beta (i.e. locally).
What I did to resolve it:
Uninstall all ServiceStack dependencies from the Solution via NuGet
Deleted the Solution's Nuget '/packages' folder, and to re-import it using NuGet package restore
Re-added the ServiceStack references via NuGet, and checked the 'packages.config' for correct versions