Share versions between Paket dependency groups? - f#

In the examples for Paket dependency groups, there is often a "main" and "test" group:
source https://api.nuget.org/v3/index.json
storage: none
framework: netcoreapp3.1, netstandard2.1
nuget FSharp.Core
nuget FParsec
group test
source https://api.nuget.org/v3/index.json
nuget FSharp.Core
nuget FParsec
nuget xunit 2.4.1
nuget FsUnit.xUnit 3.8.0
In order to use a dependency in both the library code and the test code, I can add it to both groups.
But is there a way to say "match the version of nuget FParsec in the test and the main groups"?

I'm not sure - but what if you get rid of nuget FParsec from inside the test group and specify the one from the main group in paket.references?
paket.references
FParsec
group test
xunit
FsUnit.xUnit

I recommend you don't use a test group and you put the test libraries in the main group instead. Any packages used in test runs should match versions used by the code being tested so there's no need to resolve dependencies separately. The latest version of the SAFE template follows this approach.
Groups can be useful if you have projects/scripts that really never share the same runtime. That's why the SAFE Template uses a Build group: Those dependencies are used in a FAKE script that don't depend directly on the rest on the app code.

Related

How to use GitVersion.Msbuild version 5.10.3 and GitVersion.Msbuild version 5.10.2 in the same solution

I have a solution that has two class libraries lets say A.csproj and B.csproj. Library A is in .NET Framework 4.8 and library B is in .netstandard2.0. A is using GitVersion.Msbuild 5.10.3 and if I try to use the same package version for library B then the build fails in the azure pipeline. But if I use GitVersion.Msbuild 5.10.2 (or any other lower version) for library B, then the build gets successfully run in the azure pipeline.
I am using below import statements in the csproj files.
For .NET Framework:
<Import Project="..\common\packages\GitVersion.MsBuild.5.10.3\build\GitVersion.MsBuild.props" Condition="Exists('..\common\packages\GitVersion.MsBuild.5.10.3\build\GitVersion.MsBuild.props')" />
For .netstandard2.0:
<Import Project="..\common\packages\GitVersion.MsBuild.5.10.2\build\GitVersion.MsBuild.props" Condition="Exists('..\common\packages\GitVersion.MsBuild.5.10.2\build\GitVersion.MsBuild.props')"/>
While restoring the packages only GitVersion.MsBuild.5.10.3 folder is created locally for .NET Framework library but GitVersion.MsBuild.5.10.2 is not getting created locally for .netstandard2.0 library. If this folder gets created then the solution will get build in both local and azure pipeline.
So in summary I want to use two different versions of GitVersion.Msbuild:- version 5.10.3 for .NET Framework and version 5.10.2 for .netstandard2.0 libaries. I want GitVersion.MsBuild.5.10.2 package folder also to be created inside ..\common\packages.
P.S.: Both the libraries are present in the same solution.
I have tried manually adding the GitVersion.MsBuild.5.10.2 folder in ..\common\packages but that is not the right way and if I remove it, while restoring the nuget packages doesn't get created for .netstandard libraries. Even I tried using the dotnet restore command from the command line that also did not create the package folder.
It should not require you to install multiple version of the same package and also having .NET Framework 4.8 and .netstandard2.0 projects should not create any problem. You have to build and restore the .netstandard libraries separately in the azure pipeline. In the yml file just add the below task:
- task: DotNetCoreCLI#2
displayName: 'Restore netstandard libraries'
inputs:
command: 'restore'
projects: '**/*.csproj'
nugetConfigPath: '$(ProjectName)\$(NugetConfigPath)'
env:
ARTIFACTORY__API_KEY: $(ARTIFACTORY__API_KEY)

No Dependencies are automatically installed when adding nuget package

I'm creating a small nuget package for internal using (I created .NET standard project to use both .NET Framework or .NET Core). I created a Build Definition to build the library then push it to the Nuget Feeds of my company.
I have 2 questions:
How can I set it automatically increase the version of the my nuget package when Queue the build in tfs 2017 & Can I set some information like Author, Company...for my package?
After having the Package in the TFS Packages. I tried to add my nuget package to my project. The nuget referenced package were not automatically added to the project. I can see, it displayed "No dependencies" but in fact, I used 2 packages in my library are Newtonsoft & StackExchange.Redis. So when I run the debug, error shown "Could not find the StackExchange.Redis..."
That's strange
In my Libary project setting, I can see
There are two ways to package nuget packages. You can use "nuget pack" or "dotnet pack" (if you have some dotnet core in your solution). The difference is that dotnet pack will create a dependency section in your nuspec and you would see dependency upon installing where nuget pack will not by default unless you use an actual nuspec file. If you do create a nuspec file, you'll need to add the dependency section to you file in order to have them pop up at installation. Check here for info on the nuspec file.
For you version number it's also actually in the nuspec file in the metadata section there is a tag with the version you want. The TFS nuget pack task as a drop down you can use to send in a version number. For this task you can either use a nuspec file or the csproj directly.
You have the same options for dotnet pack using the dotnet core task
Update:
If you change your build number version pattern in the options tab for a 4 (or 3) digit pattern like $(Date:yyyy.MM.dd).$(Rev:r) e.g. 2020.03.05.xx (where xx will increment for each build in the same day and go down to 1 the next day) or 1.0.$(Rev:r) which will be 1.0.xx that will increment forever until you change the 1.0 value and then use the "Use Build Number" it will do it for you.

How do I discover and run fsunit.xunit tests in F# in Visual Studio?

I am new to unit testing, but I want to experiment with xunit in F# (in a fresh VS2015 install). I created a new library, ran:
Install-Package fsunit.xunit
... and I can create a test:
[<Fact>]
let test () = "Yay"
, but when I right-click and do "Run Tests", it doesn't find my test.
When I search the extensions, there's a "xUnit.net runner for Visual Studio" in the online search results, but it says "NO LONGER NEEDED. Please un-install this extension." So I don't want to install that.
What am I missing, to enable the tests to be discovered and run?
I needed to install both the FSunit package and this test runner:
Install-Package fsunit.xunit -prerelease
Install-Package xunit.runner.visualstudio
(The current released version does not support the latest version of xunit, hence -prerelease.)

What's the difference between pub dependencies and dev_dependencies?

What is the difference in dependencies and dev_dependencies in a pubspec.yaml? It seems that when I run pub get the dev_dependencies aren't downloaded.
dev_dependencies are dependencies that are not available for code in the resulting application, but only for tests, examples, tools, or to add executable tools like for code generation to your project.
dev_dependencies of any dependencies in your project (dependencies or dev_dependencies) are always ignored when you publish to pub.dev.
See also https://dart.dev/tools/pub/pubspec
There are two types of dependencies, one is regular and the other is dev.
dependencies:
Regular dependencies are listed under dependencies:—these are packages that anyone using your package will also need.
dev_dependencies:
Dependencies that are only needed in the development phase of the package itself are listed under dev_dependencies.
If your package (say A) depends on another package (say B) (which has dev-dependencies), then your package A ignores the dev-dependencies of package B.
However, your package A depends on the packages listed by Package B's dependencies.
Pub supports two flavors of dependencies : dependencies and dev dependencies.
Dev dependencies differ from regular dependencies in that dev dependencies of packages you depend on are ignored.
Here’s an example:
Say the transmogrify package uses the test package in its tests and only in its tests. If someone just wants to use transmogrify—import its libraries—it doesn’t actually need test. In this case, it specifies test as a dev dependency.
Its pubspec will have something like:
dev_dependencies:
test: '>=0.5.0 <0.12.0'
Pub gets every package that your package depends on, and everything
those packages depend on, transitively. It also gets your package’s
dev dependencies, but it ignores the dev dependencies of any dependent
packages. Pub only gets your package’s dev dependencies. So when your
package depends on transmogrify it will get transmogrify but not test.
The rule for deciding between a regular or dev dependency is simple: If the dependency is imported from something in your lib or bin directories, it needs to be a regular dependency. If it’s only imported from test, example, etc. it can and should be a dev dependency.
Using dev dependencies makes dependency graphs smaller. That makes pub run faster, and makes it easier to find a set of package versions that satisfies all constraints.
Here, You can learn more about dependencies

NuGet - dependency installed but not found

I have a problem with the NuGet package manager. I published my library (a type provider, but I don't think this matters) and then testet it, but it fails to find a dependency. The complete error message is (full namespace/name ommitted for brevity):
The type provider 'TypeProviderImplementation....' reported an error:
Could not load file or assembly 'dotNetRDF', Version=1.0.3.0, Culture=neutral, PublicKeyToken=...' or one of its dependencies.
The thing is that when installing the library, it looks like the dependencies are installed correctly. The correct libraries are downloaded and there is no error showing up.
In an attempt to solve the problem, I specified the exact version in the .nuspec file, but this didn't change anything.
...
Installing dotNetRDF via NuGet and then manually referencing my precompiled DLL (without going through NuGet) seems to work fine.
So I'm basically out of ideas on how to solve or even debug the problem. I'm thankful for any pointers.
Addign more information about .NET version numbers as my comment below is quite hard to read:
I checked framework versions as suggested. I did this via looking at the FrameworkDisplayName in the object browser. Basically, my library was using 4.5 and dotNetRDF was using 4.0.
I switched to .NET 4.0, but nothing changed.
My library = ".NET Framework 4"
dotNetRDF = ".NET Framework 4"
HtmlAgilityPack = ".NET Framework 4.5"
Newtonsoft.Json = ".NET Framework 4.5"
VDS.Common = ".NET Framework 4 Client Profile"
My dependency is dotNetRDF, the remaining ones are dependencies of dotNetRDF.
Latest NuSpec file can be found here. I create the package via the command nuget pack LITEQ.fsproj -Prop Configuration=Release.
The package id is LITEQ.RDF.
Some additional information:
The library is a F# project. I just tested what happens if I create a console project and install the library via NuGet and then send the references to the F# Interactive Console. It actually works in this case.
So it feels like there is some problem with the project configuration after installing the library via NuGet.
To reproduce, the error, download the library, open up the UniKo.West.Liteq namespace and for example use the NpqlTypeProvider:
open Uniko.West.Liteq
type A = NpqlRdfProvider< #"">
Certainly for me I can't see any obvious problems, when I install your package into an empty console project I don't have any issues and I can write a trivial example that uses the dotNetRDF APIs just fine. If you can produce a minimal example project into which installing the packages creates an issue then that would be very helpful.
Your Issue
However the dependencies you state for your project look wrong, you have .Net 4.0 for your project and some dependencies but .Net 4.5 for others which will not work. Note that when you downgrade a projects target framework NuGet does not cope nicely with that, it is best to completely uninstall and reinstall NuGet packages any time you change the target framework version. It is perfectly fine for a newer version of the framework to rely on dependencies that target older versions, so your .Net 4.5 project can happily depend on the .Net 4.0 version of dotNetRDF. However the reverse is not true which may be the cause of your problems.
You can sometimes tell if this is the case because VS may highlight bad dependencies under References in the solution explorer with little warning icons (sadly it doesn't always do this). Even if this is not the case you should see output like the following in the Output Window when you try and build if you have incompatible dependencies and this may also yield compile errors about missing namespaces:
C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5):
warning MSB3274: The primary reference "HtmlAgilityPack" could not be
resolved because it was built against the ".NETFramework,Version=v4.5"
framework. This is a higher version than the currently targeted
framework ".NETFramework,Version=v4.0".
So I would strongly suggest that you uninstall all packages via NuGet and reinstall them whenever you change the target .Net framework of your project.
Other Issues
In terms of other possible issues you are using dotNetRDF 1.0.3 which is not the latest version, versions prior to 1.0.5 have a known issue related to interactions with the versioning and framework profiles of Json.Net. If a project you are installing into also has dependencies on Json.Net you may run into version conflict issues. See CORE-405: Resolve Issues with Json.Net dependency for some discussion on this.
I would suggest that you also upgrade your dependency to the latest dotNetRDF release which is 1.0.6.3421 at the time of writing this answer and see if that resolves your problem.
Edit - NuGet Package Versions
NuGet packages versions do not have to correspond to the assembly version, as it happens 1.0.6.3421 does have an assembly version of 1.0.3.0. That was actually not our intention but a flaw in our build process but that isn't really relevant here.
What it looks like is that your library is compiled against a different version of dotNetRDF than the one NuGet is installing for you. However without seeing the source of your package it is impossible to debug further.
What if neither solution works?
If neither of these things resolves your problem then you are going to need to provide a minimal project that reproduces the problem.
A temporary solution (or more of a hack) is to not rely on dependencies, but to directly put the DLLs into the NuGet package. When I do this, the library works fine. The NuSpec file in this case looks like this (excerpt):
<package>
<metadata>
...
</metadata>
<files>
<file src="bin\Release\dotNetRDF.dll" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.dll" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.pdb" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.xml" target="lib/net40" />
...
</files>
</package>
But obviously, this isn't a good solution.

Resources