We Keep Coding

Azure Function Queue Trigger Adding Nuget Package

I'm using Azure Function through the Azure Portal for Queue Triggers and I want to add a NuGet Package to it.
There is only two files "run.csx" & "function.json"
The function.json just contains the binding information. However, how do I add a NuGet package such as "Azure.Messaging.ServiceBus" to that function.json. I can't seem to find a clear document or explanation on how to do so.

Per the documentation, for C# Script (.csx) functions, you can upload a function.proj file that contains a PackageReference to a nuget package. This is similar to a .csproj file. In your case, it should probably be like so:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Azure.Messaging.ServiceBus" Version="7.1.2" />
</ItemGroup>
</Project>

Azure function uses incorrect DLL version

I have created an Azure function that is called via webhook from Dynamics 365. A simple scenario to read the remote context object does work; however, a more complex scenario throws an error. Tried to get an instance of the Dynamics service object using CrmServiceClient (Microsoft.Xrm.Tooling.Connector) but it throws an error when this line runs CrmServiceClient client = new CrmServiceClient(crmConnectionString):
"Could not load type 'Microsoft.IdentityModel.Clients.ActiveDirectory.PromptBehavior' from assembly 'Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.14.2.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35'"
I have checked the DLLs in the bin directory in Azure and the version for Microsoft.IdentityModel.Clients.ActiveDirectory is 2.22.
Also, I checked the xxx.deps.json file in Azure and it shows the same version:
"Microsoft.IdentityModel.Clients.ActiveDirectory/2.22.0.0": {
"runtime": {
"Microsoft.IdentityModel.Clients.ActiveDirectory.dll": {
"assemblyVersion": "2.22.0.0",
"fileVersion": "2.22.30211.1727"
}
}
I have searched for version 3.14.2.11 for the mentioned DLL but cannot find it. So I wonder why is Azure loading that version?
Following the advice of some other postings, I have added a file -function.proj- under my function's folder with the idea to downgrade the version of that DLL that Azure loads, here's the content:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.IdentityModel.Clients.ActiveDirectory" Version="2.22.0" />
</ItemGroup>
</Project>
Unfortunately, it hasn't changed the outcome. Has anyone run into the same issue?

The package Microsoft.Xrm.Tooling.Connector is depend on .net framework 4.6.2, while your azure function TargetFramework is netstandard 2.0. So make sure your function's runtime version.
Then upgrade Microsoft.IndentityModel.Client.ActiveDirectory to 2.28.3 version.
If your function runtime is ~1, create project.json with following content.
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.IdentityModel.Clients.ActiveDirectory": "2.28.3"
}
}
}
If your function runtime is ~2, create function.proj as below.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.IndentityModel.Client.ActiveDirectory" Version="2.28.3"/>
</ItemGroup>
</Project>

Just downgrading the runtime to version 1 did the trick.

How to predict/score XGBoost or LightGBM in .NET Framework 4.6.1 application

I have a machine learning problem where I have obtained very good results on training/test data using both LightGBM and XGBoost. The next step is to obtain predictions from one of these models into an existing C# application (.NET Framework 4.6.1) Is there any library that can help me do this? What I have tried so far:
ML.NET: Should work for LigthGBM, but due to this bug it works only for .NET Core.
Windows.ML: This should be able to predict an ONNX model, and I managed to create an ONNX model from my XGBoost model. But Windows.ML seems to work only for UWP apps, at least all samples are UWP.
SharpLearning: This library has an interface to XGBoost. Unfortunately, it does not support sample weights, which I rely upon.
CNTK: Tried to load the ONNX file (similar to this example), but get: Error: ONNX (TreeEnsembleClassifier) is not supported in CNTK.
Any suggestions, or do I have to wait for ML.NET to fix the bug?

I was able to use LightGBM in a net461 console application. The above bug only occurs if you are using packages.config to manage your NuGet packages. In order to work around the listed bug in the LightGBM nuget package, you can take one of the following approaches:
Use a new "SDK-style" .csproj, but set the TargetFramework to net461.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net461</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.ML.LightGBM" Version="0.3.0" />
</ItemGroup>
<ItemGroup>
<None Update="iris-data.txt">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
Change your normal .NET Framework .csproj to use <PackageReference> instead of packages.config. You can do this in the Package Manager Settings under Tools -> NuGet Package Manager menu. "Default package management format". You can refer to the Migrate from packages.config to PackageReference document for more info.
<ItemGroup>
<PackageReference Include="Microsoft.ML">
<Version>0.3.0</Version>
</PackageReference>
<PackageReference Include="Microsoft.ML.LightGBM">
<Version>0.3.0</Version>
</PackageReference>
</ItemGroup>

Empty Nuget package for just dependencies

I have a project I'd like to put all my dependencies into one nuget package. The idea is that when I need to I can just pull in that one nuget package instead of 10 that I require. Is this possible to do?
When I created a library I removed the class file and just pulled in the dependencies but could not get a package to create.

You can do this by setting the IncludeBuildOutput property to false while creating the package.
For example [using VS 2017] -
File > New Project > .NET Core class library
Right click on project and edit csproj to have the following content -
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
<PackageId>MetaPackage</PackageId>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<IncludeBuildOutput>false</IncludeBuildOutput>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
<PackageReference Include="NuGet.Versioning" Version="4.7.0-rtm.5104" />
<PackageReference Include="NUnit" Version="3.10.1" />
</ItemGroup>
</Project>
Right click and build project
Look at the package at <project_dir>\bin\Debug\MetaPackage.1.0.0.nupkg
This will create a package that has no \lib and the nuspec file should have package reference dependencies.
You can read more about IncludeBuildOutput here.

How to include a library in .NET Core 2.0

I don't know much about .NET yet, so I guess I'm missing something obvious.
I created a library (targeted as a DLL file, set for .NET standard 2.0), packaged it both as a DLL file and as a NuGet package. Now I want to use the library in another project, on ASP.NET Core 2.0. How should I do it?
I am currently on a Linux VM, so I use Visual Studio Code, and therefore I would prefer some solution without using the full Visual Studio. I tried some solutions using the full Visual Studio, but that didn't work for me, because I haven't found a reference explorer anywhere.

You would have to reference your library in the .csproj file:
An empty .csproj file would look like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
</Project>
Now, you can have two types of references:
Project Reference - You have a project that serves as a class library in your solution and you want to reference it directly:
<ProjectReference Include="..\..\src\mylib.csproj" />
Package Reference - You have a link to a NuGet package:
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
Inside your .csproj file, the references should be inside an "ItemGroup" block, and each reference type should have its own "ItemGroup".
Here's an example of a .csproj file with some package references and some project references:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.1.0" />
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.1" />
<PackageReference Include="xunit" Version="2.2.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.2.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\src\mylib.csproj" />
<ProjectReference Include="..\..\src\mylib2.csproj" />
</ItemGroup>
</Project>

A lot of people recommend one of two solutions:
Copy the library into your solution folder.
cp -r foo/foo ./foo
dotnet sln add foo/foo.csproj
cd bar
dotnet add reference ../foo/foo.csproj
This is a terrible solution.
Don't do this (i.e., copy and paste your library code every time you want to use it. It is bad for obvious reasons).
Setup a local NuGet repository, copy your library into the local repository, and then add it.
nuget add -name "Local" -source /home/doug/packages
nuget add ~/foo/foo.nupkg -source /home/doug/packages
Then install the package:
cd bar
dotnet add package foo
This is an acceptable solution, but the workflow is quite irritating if you are actively working on your library (foo), because the -source path must be absolute.
--
I recommend you look at dotnet add package with local package file, which explains how you can have a local cache of any custom .nupkg files you want to work with.
Basically, just drop this into your solution folder:
File NuGet.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="local" value="./packages" />
</packageSources>
</configuration>
(Notice that ./packages is a relative path, that will work even when you check your project out on an entirely different machine or OS.)
Now if you call dotnet add package X it will also look for any file called x.nupkg in your ./packages/ folder.
Now if you want to use any custom local library, all you need to do is:
cp ~/foo/foo.nupkg ./packages
cd bar
dotnet add package foo
(Note: by default NuGet caches your .nupkg files in ~/.nuget and will restore packages from that folder if you call dotnet add package X, even if you have a different X.nupkg in your local ./packages folder. You may find the command dotnet nuget locals all --clear useful if you encounter strange behaviour to ensure you're getting the exact version of the .nupkg file you want, not some arbitrary cached version)

Another way to reference the local package in the .csproj file:
<ItemGroup>
<Reference Include="MyAssembly">
<HintPath>path\to\MyAssembly.dll</HintPath>
</Reference>
</ItemGroup>

Given that the DLL file you want to reference in the new ASP.NET Core 2.0 project is relatively fresh, I suspect you will need to make changes to this original DLL file as you develop the ASP.NET project.
In this situation I would add the original DLL project as part of the ASP.NET solution so you can work on both sets of source code, including setting of breakpoints within the same solution workspace.
NuGet packaging of the original DLL project can be delayed until the first release of your whole combined solution has stabilised and you want to make that DLL file available to a larger developer audience beyond the scope of your ASP.NET application.

A good solution will be to add the library (.dll file) that you want to use to the Project's References of your project in which you want to use the library:
Right Click on the project → Add → Reference → Project → Browse → Path_to_your_generated_library (.dll)
This will automatically generate the following node in the .csproj file:
<ItemGroup>
<Reference Include="DotNetCoreClassLibraryCodeParser">
<HintPath>..\..\DotNetCoreClassLibrary\DotNetCoreClassLibrary\bin\Debug\netcoreapp2.1\DotNetCoreClassLibrary.dll</HintPath>
</Reference>
</ItemGroup>