I try to add the nuget package MPAndroidChart ( https://www.nuget.org/packages/MPAndroidChart/3.0.1) to my android project. But I always get the message:
Package MPAndroidChart 3.0.1 is not compatible with monoandroid71 (MonoAndroid,Version=v7.1) / win. Package MPAndroidChart 3.0.1 supports: net (.NETFramework,Version=v0.0)
When I create a new project with the default packages.config it works with adding the project. Is there anything I can adjust with the nuspec or my project ot fix that?
My project.json:
{
"dependencies": {
...
},
"frameworks": {
"MonoAndroid,Version=v7.1": {}
},
"runtimes": {
"win": {}
}
}
Looks like a problem with the MPAndroidChart NuGet package. The NuGet package does not have the assemblies in a specific target framework inside the lib folder.
With a project that uses a packages.config file it should allow it to be installed into any project, even those which are not compatible. It looks like project.json is more strict and disallows this.
Related
Lately I created a ASP.NET MVC Core project from scratch using Visual Studio 2017 (15.6.3). I discovered the usual JavaScript frameworks:
bootstrap
jquery
jquery-validation
jquery-validation-unobtrusive
But unfortunately all Bower support is gone! There's no bower.json, no .bowerrc and no "Manage Bower Packages..." anymore:
What's wrong with Visual Studio's ASP.NET MVC Core template? Did Bower become obsolete?
Please don't duplicate this question to How to use bower packages in Visual Studio 2017 if Bower is deprecated! I don't like a fix pointing to deprecated technologies.
I'd like to narrow the question: What's the simplest (most intuitive) way to replace Bower by NPM? Like Bower did with its .bowerrc: { "directory": "wwwroot/lib" }?
Bower is actually dead.
Microsoft have a lightweight and currently under the radar solution to this called Library Manager (LibMan).
It's a stripped down json based solution, with a very simple UI - that gives you control over which files to download (no more downloading hundreds of files when you just need 1).
Mads Kristensen did a great little intro to the preview at Build 2017.
(the video should start at the correct place around 43 mins).
At the time of writing this it's still in preview - but due to be released with Visual Studio 15.8.
If you'd like to try it before that you can grab it from the GitHub Repo or Visual Studio Marketplace - instructions in the solution to this question
You can still use npm etc - though here are Microsoft's reasons for using this instead (or as well as) - from the Visual Studio Marketplace:
Reasons for using this extension
For apps not currently using another package manager
For projects where you think Bower and npm are overkill
For developers that don't want to use Bower or npm
For developers that values simplicity in their tools
For using custom or private packages/files
For ASP.NET Core apps where NuGet can't install content packages
Bower is dead. The team of bower is refering to Yarn (an addition on NPM).
Since Visual Studio has some NPM support, I would go for it.
Create in the root of your project a package.json (Todo so, right click your project, add item and search for NPM. You will find a npm Configuration File):
{
"name": "SomeName",
"version": "1.0.0",
"private": true,
"dependencies": {
"bootstrap": "3.3.7",
"jquery": "3.3.1",
"jquery-validation": "1.17.0",
"jquery-validation-unobtrusive": "3.2.10",
"jquery-ajax-unobtrusive": "3.2.4",
}
}
Everytime you make changes to the json file, simple press CTRL + S. Visual Studio automaticly calls NPM and restores the packages. Also note, you have intellisence for the package names and version numbers.
After migrating myself, I can not remember to not find a package on npm. But if it's the case for you, note you can reference a github repository directly.
The depenencies are saved to node_modules folder. That's for the new package manager.
Now you have the problem you need to bundle it for release (which you should have done with bower too). Bundeling is the process of combining your Javascript/CSS/Image assets to a single bundle.js, bundle.css, sprite.svg. These should be copied to the wwwroot folder.
For doing so, we have a few options (I will only link to a few, since this would explode the scope of the question):
Webpack
Gulp
Grunt
We found bower to be tricky to get setup, npm is well supported and packages can be installed using the Package Installer from Mads Kristensen, this also works well with the Bundler & Minifier extension, from the same developer for copying the relevant files from the node_modules folder to where you want them.
https://github.com/madskristensen/BundlerMinifier
https://marketplace.visualstudio.com/items?itemName=MadsKristensen.PackageInstaller
I would suggest just sticking with npm and forget bower for asp.net core projects,i posted a way of using npm in the link below,
How to use yarn in ASP.Net core MVC to install bootstrap in wwwroot folder
The solution is to do the following:
Launch VS 2017 and open Tools - Extensions and Updates from the main menu
In the window that opens, select Online on the left menu and type package in the Search box. Download the Package Installer
Close all VS instances and wait a while, the VS installer will start which will install that package
After installation, start VS and your project that should have a bower
Start Project - Quick Install Package from the menu
Select npm and type upgrade -g bower in the field
The previous command will update the locations of the bower packages. Now create the bower.json file manually as follows:
Right-click on the project and Add - New Item
Select the JSON file and name it bower.json
Open the file and type in the following file: {"name": "myproject"}
Create another JSON file that you will only call .bowerrc
Open the .bowerrc file and type the following:
{
"directory": "wwwroot / lib /",
"registry": "https://registry.bower.io"
}
Right-click the bower.json file and select the Manage Bower Package option.
In the Browse section, type mustache.js and install
When you click on Project in the window you will see Manage Bower Package
That is all!
The following blog worked for me, although it claims the issue would be fixed in 15.8 which is the opposite of this issue:
https://blogs.msdn.microsoft.com/webdev/2018/07/05/workaround-for-bower-version-deprecation/
I have updated the .bowerrc file to include:
"registry": "https://registry.bower.io"
I then right clicked the bower.json and Restore packages. Then voila!
I have an F# project that uses FSharp.Core version 4.1.0. When I upgrade to version 4.1.12, NuGet adds the following files to my project's source code directory:
any/netstandard1.6/FSharp.Core.sigdata
any/netstandard1.6/FSharp.Core.optdata
I expect NuGet to add files under the packages directory, not directly into my project. Having these files appear alongside .fs files in the project's source code tree seems odd. Is this expected behavior? Can I safely delete these files (since copies presumably exist under packages as well)?
Here's an example of what I see:
I'm trying to automate the building of a ASP.NET Core application that has two types of dependencies to Nuget packages that are part of the same project:
Direct dependency to a Nuget package also being actively developed as part of the effort
Reference to "classic" .NET assembly projects in the same solution, where those projects have dependencies on Nuget packages we're also developing
I want a build of this solution to get the latest versions of our Nuget packages and then "do the right thing."
Let's start with #1 above:
With dnu install (deprecated) I can effectively update to the latest version of a Nuget package; however, this is only if I am running dnu install in the same directory as my xproj. Why? because there are three positional (but AFAICT unnamed) arguments: package id, version, project location - so if I want to specify project location, I have to put in a version, but what to put if I want the latest? Tried * but that didn't work.
Ideally, I'd like to use the Coreclr dotnet client anyway, but that - by design - has no install option.
Now Case #2
My 'classic' assembly projects have a prebuild step using nuget update that pulls the latest nugets for our project and builds appropriately (which is analogous to my case #1).
HOWEVER, it doesn't appear that references to those projects in my ASP.NET Core application are being updated, although the ASP.NET project is rebuilt. In Solution Explorer, the versions of the dependent nugets remain at the version they were when I added them manually as references. The only way I've found to fix - even when just working in Visual Studio - is to remove the references and then re-add them (as if the 'wrap' mechanism doesn't automatically kick in).
All this makes me think that it's really not possible to completely automate this build - hoping that I'm wrong :)
Revised to include more details below
Here is the project structure as shown in Visual Studio, at the point that it all builds correctly.
Here is global.json:
{
"projects": [
"src",
"test",
"wrap"
],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
And here is the complete project.json for the API project:
{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Lnl.Saas.Diagnostics": "1.0.0-*",
"Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.TraceSource": "1.0.0-rc1-final"
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
},
"frameworks": {
"dnx452": {
"dependencies": {
"Account.Model": "1.0.0-*",
"Account.Service": "1.0.0-*"
}
}
},
"exclude": [
"wwwroot",
"node_modules"
],
"publishExclude": [
"**.user",
"**.vspscc"
]
}
Now I rebuild the projects (not shown) that create the Nuget packages referenced in the solution above.
Then I'd like to be able to rebuild the Account solution above to pull in the updated Nugets
The latest version of Lnl.Saas.Diagnostics directly into the API project
Two other Nugets into the Service project (this works via a nuget install post-build) and then update the reference to Service in the API project so it references the NEW nugets.
Note below that the Diagnostics Nuget reference did not change (neither did the ones in Service, but I forgot to expand it on the first screen shot)
If I look in the Nuget package manager UI, it's aware that there are updates, and if I use the UI they are applied.
If I run dnu restore in the package manager console, it lists the new packages but (re?)installs the previous ones - which are explicitly named in project.lock.json.
From trying to piece together documentation, I got the impression dnu restore was doing the 'right' thing here and I needed to use dnu install, which does work if I run it in the same directory as the project.json file (but if I try to run from another directory, where my automation scripts lie, I can't/don't know what to put in the version (2nd) argument, which is now required because I'm supplying a project location (3rd) argument).
The documentation at http://docs.asp.net/en/latest/dnx is sorely lacking, and when following some links, I got to the dotnet.github.io project which has better documentation (but not an obvious mention that it applies to rc2).
Lastly, and perhaps this offers some addition clues, is that on build I get a warnings (which don't appear to cause issues at runtime) like:
Warning MSB3274 The primary reference
"C:...\Account\Service\bin\Debug\Account.Service.dll" could not be
resolved because it was built against the
".NETFramework,Version=v4.5.2" framework. This is a higher version
than the currently targeted framework ".NETFramework,Version=v4.5.1".
but have no idea how to resolve since I don't where/how I'm targeting the 4.5.1 framework with the API project.
I tried the new ASP.NET vNext and I really liked the way gulp worked. I'm trying to compile LESS using gulp in an ASP.NET 4.5.2 MVC project now.
I followed this for help.
Here's what I've done so far:
Added a package.json file with the following code.
{
"name": "package",
"version": "1.0.0",
"private": true,
"devDependencies": {
"gulp": "3.9.0",
"gulp-bower": "0.0.10",
"gulp-config": "0.3.0",
"gulp-less": "3.0.3",
"gulp-plumber": "1.0.1"
}
}
Created a Gulp Task in gulpfile.js
var gulp = require('gulp');
var less = require('gulp-less');
var path = require('path');
var plumber = require('gulp-plumber');
gulp.task('less', function () {
return gulp.src('./Content/**/*.less')
.pipe(plumber())
.pipe(less({
paths: [path.join(__dirname, 'less', 'includes')]
}))
.pipe(gulp.dest('./content/'));
});
But then I get the following error (in the output window):
Failed to run "C:\Users\me\documents\visual studio 2015\Projects\projectname\Gulpfile.js"...
cmd.exe /c gulp --tasks-simple
'gulp' is not recognized as an internal or external command,
operable program or batch file.
I'm guessing npm din't download gulp. Any idea how to get this working?
You shouldn't need to install Gulp globally to work with it in Visual Studio 2015. When Gulp is installed into the project by npm, it adds gulp.cmd to a folder in your project (./node_modules/.bin by default). Visual Studio includes that path by default in the paths where it looks for external tools like Grunt, Gulp, Bower, and npm. This is configurable in Tools->Options->Projects And Solutions->External Web Tools.
My guess is that npm didn't successfully install the packages when you first created the package.json file. Whenever you save your package.json file, Visual Studio will run npm install for your project, so you don't even need to open a console window. But if you added an existing package.json file to the project, it doesn't install for you automatically. In that case you need to run npm install yourself, or open and save the file to get VS to do it for you.
Typing npm install in the Package Manager Console will add a node_modules folder to the project. All of the dependencies specified in the package.json file will be added to that folder.
In this case, now that gulp is installed, the error should be gone.
The short answer is, to get rid of this error, install gulp globally with the following command:
npm install gulp -g
In VS2015 RC gulp had to be installed globally. Otherwise VS wouldn't recognize it. You can find a detailed explanation here: http://www.dotnetcurry.com/visualstudio/1096/using-grunt-gulp-bower-visual-studio-2013-2015
Is supposed to be fixed in VS2015 RTM, I haven't checked that yet though.
Running npm install for the separate packages should not be necessary. If you enable hidden folders, you should see that VS downloads all nodejs modules by default after you saved your package.json file. The download log can be found in the output window "Bower/NPM" in VS2015 RTM. If you enable hidden folders or take a look in your web project directory, you should see a node_modules folder with all the packages specified in your package.json file.
In my case I needed to move
$(PATH)
before
.\node_modules\bin
I have found if you create the visual studio solution folder on a UNC path this error will occur.
Often UNC paths map your Documents folder when using a windows on virtual machine (e.g. Parallels for Mac).
To fix the issue I moved the visual studio solution folder to the virtual machine disk drive, then reopened the project.
I have a mvc 5 web project with a number of NuGet packages installed (like email, log, pagedlist etc).
In a new similar project I would like to install the same NuGet packages. How can I in the old project list all installed NuGet packages?
You can find a packages.config file in the old project's root directory.
You can copy it to the new project.
If you go to Tools -> NuGet Packet Manager -> Packet manager settings and check Allow NuGet to download missing packages and the other check box that states Automatically check for missing packages during build in Visual Studio it will download it for you next time you build.
If you want to list all installed nuget packages for the project take a look at this one.
http://blogs.msdn.com/b/david_kidder/archive/2014/08/19/micro-blog-how-to-list-installed-nuget-packages-from-package-manager-console-and-be-able-to-read-them.aspx
You might also want to enable nuget package restore to restore the packages when rebuilding your project/s.
Here's another link for you - http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
In the root folder of your original project find a packages.config file. Copy its contents to your new project, same file name.
Go to Visual Studio > Tools > Package Manager Settings > General
Enable "Allow Nuget to download..." and "Automatically check for missing..."
Now build your new project
Most of the answers here are partially correct.
The first part is true. The packages.config file lists all packages that are used by the project.
However, all the answers about using Package Restore are incorrect. Package Restore will download any missing packages, however it is NOT the same as installing a package into a project. It will not add references, run any install.ps1 scripts, or add files, modify .config, etc. Package Restore simply downloads missing packages. It is assumed that the packages were already installed to the project.
In order for the packages to be correctly installed in your new project, open the Package Manager console, then type:
Update-Package -ProjectName MyProjectName -Reinstall
This will force NuGet to run through the install process and correctly install the package into your project.