I just downloaded the FSlab journal template from fslab.org. when I try to run the tutorial.fsx I get a number of errors in the build.fsx. These errors seem to be specific to the suave library.
The first issue is “open Suave.HTTP.Files” apparently there is no Files namespace.
Second, the script uses an UTF8 data type that cannot be found.
Third, the script also uses an Applicatives type that cannot be found.
When I went on github to look at Suave I found that the Suave.HTTP.Files namespace had been deprecated in favor of Suave.Files but when I added that namespace it didn’t fix anything.
I am using paket to pull the latest versions of all the dependencies. I am using VS 2013.
Is there some step in FsLab journal template that I am missing? Is the latest version of Suave no longer compatible with FsLab?
Can you please open an issue for this on FsLab's GitHub?
The FsLab template always gets the latest version of all dependencies, which works fine when there are no breaking API changes. Suave 1.0 (released just now) went through a lot of much needed cleanup, but it has breaking API changes.
We'll need to update the template to the latest version of Suave. In the meantime, you can explicitly require version 0.33.0. I just did this change in the template - all you need to do is to add the version number in paket.dependencies:
nuget FsLab
nuget FsLab.Runner
nuget FAKE
nuget Suave 0.33.0
When you change the last line as above after downloading the template, things should work!
Related
When i try create new blank application in nanoframework, i get package installation error.
error message
It seems some problem in nanoframework visual studio extension, my version is NET nanoFramework VS2019 Extension v2019.5.0.8.vsix, but i also tried another versions with same problem.
I have visual studio 2019 community edition and i have installed almost all components.
When i press ok, project is loaded, but is not possible compile it, because there are missing all assemblies. When i try add assembly, theres nothing to add and add nuget packages from nanoframework store leads to error.
when i try this:
pm> Install-Package nanoFramework.CoreLibrary.NoReflection -Version
1.10.1-preview.9
I get this error:
NU1202: Package nanoFramework.CoreLibrary.NoReflection
1.10.1-preview.9 is not compatible with netnanoframework10 (.NETna noFramework,Version=v1.0). Package
nanoFramework.CoreLibrary.NoReflection 1.10.1-preview.9 supports: net
(.NETFramework,Version=v0.0)
similiar when i try another package versions.
So the extensions is installed incorectly, but i cant find why. i tried it more times. uninstall and install again. from extenstion store, and from disc. nothing successfull.
The webserver NuGet released today fixes the issues with the version mismatches.
The issue with VS2019 16.9 remains. Reported to VS Developer Community here. Please up vote to help increase priority.
What is the Community version you're using?
After a little test, there seems to be an issue with the latest release of VS2019. A work around would be to:
Use V16.8.X
or
use an already created solution that you can edit.
or
add the required nuget to the project once it has been loaded (after the error):
Update: now fixed! it was due to a change to fix nuget, but caused an unintended consequence with nanoFramework.
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.
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.
I created a new Project in Visual Studio 2013, a WebApi & MVC 5 project and updated all nuget packages. It updated to mvc 5.1. Now I cannot Successfully build the project it says
assembly uses System.Web.Http 5.1.0.0 which has a higher version than referenced assembly System.Web.Http 5.0.0.0
Anyone run into this before? Why these kind of problems do occur so often in Visual Studio? Does anybody know how to solve this because I really am trying hard but no luck so far...
Solved
I opened the Package Manager Console in Visual Studio and run the command
PM> Update-package
It magically resolved everything for me. You can find Package Manager Console under
Tools
Nuget Package Manager
Package Manager Console
This command deletes all the old packages under the package folder and updates everything if necessary, you may also run the command on a specific package. Here all the variants of the command http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference#Update-Package
Let me know if you found this useful I'm curious to know if it just happened to me accidentally
A new version of ASP.NET was released. Announcement here : http://blogs.msdn.com/b/webdev/archive/2014/01/20/announcing-the-release-of-asp-net-mvc-5-1-asp-net-web-api-2-1-and-asp-net-web-pages-3-1.aspx
You probably have two projects in your solution, where project A references project B. Both projects reference ASP.NET, but there is a version mismatch.
I had a very similar problem to yours exactly with a reference to System.Web.Http and have documented it here:
Could not load assembly error
When you update a Nuget package it would update dependent packages. But it would not update other packages in your solution that depend on the updated packages. These other packages might not even have a newer version built with the udpated packages.
So the solution is either to udpate all your packages like you did (this might not always work) or add binding redirects to the latest version of your assembly reference to your application config.
I solved this way. As I currently have fwk 4.0.0.0 and don't want to install 5.X:
I removed the referenced DLLs
I removed a couple of bindingRedirects at packages.config,
Then I rebuilded that solution, that throws me errors
Then I added the reference again
And voilà, the solution is running with the fwk that I have.
I am using EF 4.0, at the time I am writing these lines I heard that EF 4.1 update 1 has been released and EF 4.2 is in beta. From wikipedia
A refresh of version 4.1 named Entity Framework 4.1 Update 1, was
released on July 25, 2011. It includes bug fixes and new supported
types.
But I only found a link of Version 4.1.10311.0 from Microsoft which date published is 3/21/2011. So I wonder if version 4.1.10311.0 is the latest release so far. If it's not, where can I download the latest release ?
ps : For some reasons I can't use live update, I need to download package to install manually.
From Arthur Vickers:
What if I can’t use NuGet? What if you can’t connect to the Internet
from your development machine. Or what if you are not allowed to
install NuGet on your machine. Don’t worry; all is not lost.
First you need to get the NuGet package. For this you do need to be
able to connect to the Internet from some machine—but it doesn’t have
to be your development machine. You’re reading this so presumably
you’re not completely off-the-grid. :-)
You can get the package by using NuGet in Visual Studio on a machine
connected to the Internet in the normal way—just install the package
you want into a dummy project. After installing the package you can
find the .nupkg file either in the dummy project folder or by browsing
the Package Cache from the Package Manager Settings menu option.
You can also get the package without Visual Studio by using NuGet.exe.
If you are able to install NuGet on your development machine then do
so and setup a local feed. This may sound daunting but it’s really
easy. Copy the .nupkg file to your local feed and then use NuGet to
install it in the normal way—with no connection to the Internet
required.
If you can’t install NuGet on your development machine then take the
.nupkg file and rename it to .zip—yep, it’s a zip file. You can now
extract EntityFramework.dll from the zip file and use it as you would
any other assembly. Note that you will not get any of the automatic
project-level integration I mentioned above, so you may have to do
more manual configuration of your project.
If you are using EFv4.0 you mostly don't need EFv4.1 or EFv4.2. Those versions bring new type of mapping (code first / fluent) and new DbContext API which can be used instead of ObjectContext API. So unless you want to start a new project with those "new" features or completely migrate your existing project you don't need it. Real new functionality for you will be included in .NET 4.5. DbContext API and code first is shipped only as NuGet package since EFv4.2.
use the package-manager in VS2010 to install
Tools + Library Package Manager + Nuget package manager
EF 4.2 has just been released: http://blogs.msdn.com/b/adonet/archive/2011/11/01/ef-4-2-released.aspx
This is a minor update over 4.1.
The runtime components are available via NuGet. The designer etc. updates for VS are a separate install.