Remove compiler warnings when using F# on .NET core - f#

When I build using .NET core (dotnet build) I get the following kinds of warning:
warning NU1701: Package 'FSharpx.Async 1.13.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project.
However, the package does actually work correctly with my project.
How can I fix this warning?

Related

How to change TypeScriptToolsVersion from 3.7 to 3.8

I am developing a project in VS2019. When I compile it, I receive the following warning:
warning : Your project specifies TypeScriptToolsVersion 3.7, but a matching compiler was not found. The latest available TypeScript compiler will be used (3.8). To remove this warning, install the TypeScript 3.7 SDK or update the value of TypeScriptToolsVersion.
I was trying to find where TypeScript version is specified but I did not find it. Microsoft.TypeScript.targets does not define it, however, if it would, I think I could change the value by not modifying that file directly.
Where can I fix that?
Jaime
Go to your project Properties -> "TypeScript build" tab and in the field: "TypeScript version" either choose specific version or select "Use latest available"
Look for TypeScriptToolsVersion tags in your csproj files and update to required version.
#BogdanRB answer above only displayed "Use latest available" and "4.2" for me. I did some research and apparently "4.2" is the SDK version installed together with Visual Studio 2019 (which I couldn't remove since it's required for lots of other VS components).
I was working on a legacy project that uses TypeScript "3.1.1", the version specified in package.json installed via npm. In order to line up the editor's IntelliSense and the compilation, and avoid using unsupported TS syntax, I've opened my ASP.NET Core MVC .csproj file and removed the following line:
<TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
Now Visual Studio's IntelliSense is compatible with the one specified in the npm package. It even works inside *.vue templates, in case you're using Vue with TypeScript.

F# (mono) for VS Code on MacOS : bugs

I'm trying to use F# with VS Code (v1.17.2) on MacOS (Sierra 10.12.6)
I think i've installed latest versions of Mono and .NET SDK
I'm trying just to build the simple project described here as a test
https://github.com/s952163/FSharpVSCode
after my default installation, I could do a MSBuild and run the program in the terminal without any problem. However at that stage,
(1) Intellisense is not working properly, not recognizing Deedle
(2) in the F# explorer it would say
'TestProject1.fsproj (load failed)
when doing a right-click i got this error
Error: MSBuild failed with exitCode 1 Working Directory:
'/Users/francois-guillaume.rideau/Documents/FsharpVsCode/TestProject1'
Exe Path: 'dotnet' Args: 'msbuild
/Users/francois-guillaume.rideau/Documents/FsharpVsCode/TestProject1/TestProject1.fsproj
/p:SkipCompilerExecution=true /p:ProvideCommandLineArgs=true
/p:CopyBuildOutputToOutputDirectory=false
/p:UseCommonOutputDirectory=true /t:_Inspect_FscArgs
/p:_Inspect_FscArgs_OutFile=/var/folders/gm/z065gk616xg6g0xgn4c7_bvc0000gn/T/tmp52c377ed.tmp.FscArgs.txt
/p:DesignTimeBuild=true /t:_Inspect_GetResolvedProjectReferences
/p:_Inspect_GetResolvedProjectReferences_OutFile=/var/folders/gm/z065gk616xg6g0xgn4c7_bvc0000gn/T/tmpfe4a2c2.tmp.GetResolvedProjectReferences.txt
/t:_Inspect_GetProperties
/p:_Inspect_GetProperties_OutFile=/var/folders/gm/z065gk616xg6g0xgn4c7_bvc0000gn/T/tmpfe4a2c2.tmp.GetProperties.txt
/nologo /verbosity:quiet' Log: writing helper target file in
'/Users/francois-guillaume.rideau/Documents/FsharpVsCode/TestProject1/obj/TestProject1.fsproj.proj-info.targets'
/usr/local/share/dotnet/sdk/2.0.2/Microsoft.Common.CurrentVersion.targets(1122,5):
error MSB3644: The reference assemblies for framework
".NETFramework,Version=v4.6.1" were not found. To resolve this,
install the SDK or Targeting Pack for this framework version or
retarget your application to a version of the framework for which you
have the SDK or Targeting Pack installed. Note that assemblies will be
resolved from the Global Assembly Cache (GAC) and will be used in
place of reference assemblies. Therefore your assembly may not be
correctly targeted for the framework you intend.
[/Users/francois-guillaume.rideau/Documents/FsharpVsCode/TestProject1/TestProject1.fsproj]
to try to solve this, i typed in the following
export FrameworkPathOverride=/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/
but worse, after that, the project doesn't build anymore in VS Code as I get this output when trying (Cmd-Shift-P) MSBuild: Build Project
/usr/local/share/dotnet/sdk/2.0.2/Microsoft.Common.CurrentVersion.targets(1122,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6.1" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [/Users/francois-guillaume.rideau/Documents/FsharpVsCode/TestProject1/TestProject1.fsproj]
screenshot here https://imgur.com/KtMM2Bu
VS Code environment is passed to msbuild when it invokes it, so setting environment variables on startup of VS Code does the trick:
FrameworkPathOverride=/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/ code .
Go to project location in the terminal and then run FrameworkPathOverride=/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/ code . as said before.
Then you should be able to build again.

TFS Build The reference assemblies for framework ".NETFramework,Version=v4.6" were not found

A TFS 2012 build server with .NET 4.6 installed produces the error message below when trying to build a website targetting .NET 4.6.
The machine has been restarted since the install.
Do I need to somehow tell TFS to favor .NET 4.6?
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(983): The reference assemblies for framework
".NETFramework,Version=v4.6" were not found. To resolve this, install
the SDK or Targeting Pack for this framework version or retarget your
application to a version of the framework for which you have the SDK
or Targeting Pack installed. Note that assemblies will be resolved
from the Global Assembly Cache (GAC) and will be used in place of
reference assemblies. Therefore your assembly may not be correctly
targeted for the framework you intend.
I installed the .NET Framework 4.6 Targeting Pack on the build server and that resolved it for me.
Firstly, you need to be sure that all referenced assemblies in the project can be found on the TFS build server. For best practice, you need to install VS2015 on the build server machine.
Secondly, you need to customize your TFS build process template to explicitly set the ToolPath variable in the Run MSBuild for Project activity to be C:\Program Files (x86)\MSBuild\14.0\Bin. Or add /tv:14.0 argument to MSBuild command.

How to resolve reference errors in Code Analysis of MVC.net project using Team City

When using Team City for CI builds there is an option to use the Resharper command line tools to run Code Analysis inspection of the code as one of the build steps.
I have this working with reference library projects but the mvc.net project in the solution fails with reference errors:
One or more types required to compile a dynamic expression cannot be
found. Are you missing references to Microsoft.CSharp.dll and
System.Core.dll?
Even with the default Microsoft template there are over 200 errors and they seem to all come from the razor views. (The project compiles and deploys from the build server correctly and FXCop also runs successfully, this seems to be an issue just for resharper tool.)
I can run the resharper code inspection in visual studio without errors.
In Team City I just have a default Inspection (.NET) build running pointing at the .sln file.
We are using Resharper Command Line Tools 9.1.201 as provided with TeamCity 9.0.4
What configuration or additional steps can I take to get the resharper command line tool to resolve mvc view references on the build server?
If resolving the references is not possible, can the razor views be excluded from the analysis without needing to add each exclusion to the command line?
For future reference, I just had the same issue. Digging through the build log, I noticed a seemingly unrelated warning:
The reference assemblies for framework ".NETFramework,Version=v4.5.2" were not found.
I retargeted my project to .NET 4.6 and installed the .NET 4.6 targeting pack, and the code inspection errors are gone. Unfortunately, I don't know if just installing the .NET 4.5.2 targeting pack would have solved the issue.

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