Some weeks ago, I followed this tutorial to get started with dotnet core + vue.js.
The steps to install the template were:
Install the SPA (Single Page Application) templates provided by Microsoft:
dotnet new --install Microsoft.AspNetCore.SpaTemplates::*
To get started and create a new Vue project, simply run the following commands on the console:
mkdir new-project
cd new-project
dotnet new vue
It worked perfectly (I repeat: that was some weeks ago).
Now I've repeated the same steps in the same machine and it says "There are no templates that match the name of the input template: vue" =>
Have the vue.js template been discontinued during the last weeks? Or am I doing something wrong?
After other comments saying it was working for them, and knowing that it worked for me some weeks ago, I've finally figured out what is going on:
On my "Available package sources" (NuGet config) in VS2017, I had the nuget nuget repository from work [work-repo]. I have to connect via VPN to be able to access it (and I wasn't during my tests). I didn't have it connected some weeks ago when the whole process worked perfectly.
Now, when I was executing dotnet new --install Microsoft.AspNetCore.SpaTemplates::*, the first lines were informing me that "I am not able to connect o [work-repo]". But then it seemed to continue as if nothing happened, and I ignored it because I didn't see it as something that would have anything to do with "not seeing vue".
Once I removed [work-repo] from the sources list, I have been able to see the "vue" template again. I have installed it via dotnet new vue and it works perfectly.
tl;dr: If you have "Nuget package sources" that are not accessible at the moment, the process "Install the SPA templates provided by Microsoft" doesn't work.
I had the same issue. In my case, the issue occured after installing Visual Studio 2019. After struggling for a while I found out that
the NuGet V2 package source was completely missing.
After going to Tools -> Options -> NuGet Package Manager -> Package Sources, adding https://www.nuget.org/api/v2/, the vue-template appreared after running that command:
dotnet new --install Microsoft.AspNetCore.SpaTemplates::*
I similarly found this wasn't working, and the problem was also having a private repository (that needed authentication rather than being completely inaccessible). The simplest solution for me was to list the nuget packages using 'nuget sources', check the name of the private repository, use 'nuget sources Disable -Name [privatereponame]' to temporarily disable the repo, then run 'dotnet new --install Microsoft.AspNetCore.SpaTemplates::*' to install the new templates, and finally 'nuget sources Enable -Name [privatereponame]' to re-enable the private repo that was causing the problem.
I had the same problem and it was Telerik source/package causing the issue. Once I removed iy from the "Available package sources" (just like Xavier suggests), the SpaTemplates install completed without error
Its so simple: just run
dotnet new search vue
then follow the instruction
and then select a template, enjoy
Related
When I try to add a NuGet package via the dotnet cli I get an error that it can't access one of my custom NuGet sources. Is there a way to say "I don't care, restore from where you can"?
McMaster.Extensions.CommandLineUtils clearly it exists in NuGet.org and it finds it but then stops b/c it can't access a custom source 🤷♂️.
PS c:\Temp\blah-project> dotnet add package McMaster.Extensions.CommandLineUtils
info : Adding PackageReference for package 'McMaster.Extensions.CommandLineUtils' into project 'c:\Temp\blah-project\blah-project.csproj'.
info : Restoring packages for c:\Temp\blah-project\blah-project.csproj
info : GET https://api.nuget.org/v3-flatcontainer/mcmaster.extensions.commandlineutils/index.json
info : OK https://api.nuget.org/v3-flatcontainer/mcmaster.extensions.commandlineutils/index.json 147ms
error: Unable to load the service index for source https://myinstace.pkgs.visualstudio.com/_packaging/Blah/nuget/v3/index.json.
error: Response status code does not indicate success: 401 (Unauthorized).
The dotnet command has the option to specify --source. This allows you to only restore packages from a specific location, in this case you'd want to use
dotnet restore --source https://api.nuget.org/v3/index.json`
This should pull the packages down to your local NuGet store and solve the problem on your machine.
In order to add the package to your project you may need to manually add a <PackageReference> to your project like
<PackageReference Include="McMaster.Extensions.CommandLineUtils" Version="2.6.0" />
Then running the restore command above will get the package for you.
As a more-permanent fix, you should put a nuget.config file in the root of the project/repository where you specify the package sources for that specific project. There are settings that you can set to override your system's global nuget configuration/sources. See more information on nuget.config. You can create a starting nuget.config in your repo with dotnet new nugetconfig
while restoring packages, dotnet make a call to all the package sources to get the package and uses the one that responds first.
In your case, because of some authentication issue it is not able to access that source. That source can be disabled using the below command and then try to pull the package.
dotnet nuget disable source <NAME> [--configfile <FILE>]
You might be able use the --ignore-failed-sources option.
I'd recently encountered similar issues when having authentication problems on a private feed, this allowed me to install the packages (was actually a tool using dotnet tool install) and address my auth issue at a later date.
See https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore for more info and options.
I'm attempting to use the build system in VSTS to build and deploy a c# .net web app. I've created a new single-project solution (as there doesn't seem to be any way to specify which project to build/deploy in a multi project solution!?!) and set up my build definition to point to this new solution. I've set it up to use the VS2017 build agent.
The NuGet restore completes and it begins to build but fails with the error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeployPackage.targets(124,7): Error MSB4184: The expression "[System.IO.Path]::GetDirectoryName('')" cannot be evaluated. The path is not of a legal form.
Has anyone encountered this and knows how to fix it?
Thanks
I know this might be bit late, but if it helps anyone then they should install the extension VSColorOutput
Then go to Tools => Options => VSColorOutput => General => Set Stop Build on First Error to true.
Using .Net Core step/task instead. (Command: publish; Arguments: --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory))
Similar issue: VSTS fails to build my really really simple ASP.NET Core app
Getting the following error on TravisCI when trying to build an ASP.NET Core WebApp.
Could not find project file
/usr/lib/mono/xbuild/Microsoft/VisualStudio/v14.0/DotNet/Microsoft.DotNet.Props,
to import. Ignoring.
Builds on AppVeyor. Is there any way to install the missing file?
Note that I'm new to Travis CI so please include a reference (eg. link/step by step/guide) on how to implement your suggestion, thank you.
After trial and error we've came up with this:
Put these files into the root of your repo https://github.com/aspnet/KoreBuild/tree/1.0.0/template
Copy .travis.yml from a aspnet project e.g. https://github.com/aspnet/EntityFramework/blob/dev/.travis.yml
Remove parts you don't want, like branches and notifications
Make sure your solution and global.json is in the same directory as build.sh
I haven't found any documentation for it, so if it doesn't do what you want, you can just let it install dotnet and do what you want with commands yourself (e.g. dotnet publish)
Old answer:
If you don't solve the problem with xbuild, you can try using dotnet
cli. The install script for RTM is here:
https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0-preview2/scripts/obtain/dotnet-install.sh
Then you use dotnet restore and dotnet build (cd to directory with
project.json)
Change your .travis.yml to this:
language: csharp
install: curl -s https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0-preview2/scripts/obtain/dotnet-install.sh
| bash
script:
- dotnet restore WebApp/src/WebApp/project.json
- dotnet build WebApp/src/WebApp/project.json
addons:
apt:
packages:
- gettext
- libcurl4-openssl-dev
- libicu-dev
- libssl-dev
- libunwind8
- zlib1g
I'm not sure all of the apt packages are necessary. source:
http://andrewlock.net/adding-travis-ci-to-a-net-core-app/
It's also possible to use KoreBuild
https://github.com/aspnet/KoreBuild/tree/1.0.0/template
script: ./build.sh //Add the file to repo
I'm using VS Express 2013 .Net 4.5. I'm designing in MVC5 and EF6 with MS SQLServer LocalDB in an Oracle VirtualBox Windows 7 64bit client.
I am trying to apply SQL Server LocalDb migrations with the command:
PM> Enable-Migrations -ContextTypeName SGHWA_MVC.Models.Context
This always fails.
My limited web knowledge is with Web Forms so I am completely new to MVC and EF. Also I have never used PMC and Powershell. I have searched for solutions but have not found questions similar to this error that Package Manager Console produces.
First there is a warning:-
Cannot determine a valid start-up project. Using project 'SGHWA_MVC' instead. Your configuration file and working directory may not be set as expected. Use the -StartUpProjectName parameter to set one explicitly. Use the -Verbose switch for more information.
PCM drop-down box shows the Default project correctly as SGHWA_MVC. The solution property pages show this one project as the start-up project.
I went to http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference but could not see the -StartUpProjectName parameter mentioned. I'm not sure to which command this parameter applies.
Then the first error appears:-
Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'file://\W7O2007\Users\Admin\Documents\Visual Studio 2013\Projects\SGHWA_MVC\packages\EntityFramework.6.1.0\tools\EntityFramework.PowerShell.Utility.dll' or one of its dependencies. Operation is not supported.
(Exception from HRESULT: 0x80131515)"At \W7O2007\Users\Admin\Documents\Visual Studio 2013\Projects\SGHWA_MVC\packages\EntityFramework.6.1.0\tools\EntityFramework.psm1:780 char:62
+ $utilityAssembly = [System.Reflection.Assembly]::LoadFrom <<<< ((Join-Path $ToolsPath EntityFramework.PowerShell.Utility.dll))
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
It suggests the file is not there to be loaded but it does exist on the PC at the path shown. I suspect it is the Join-Path that fails but am unsure how to test this.
The packages.config files has a line:-
(leading < removed) package id="Powershell.Deployment" version="1.1.0.0" targetFramework="net45" />
My research shows it could be permissions, remote access, that the Project Build should have Generate Serialization Assembly as 'On', 'Off' or 'Auto' or even NuGet packages that cause this but I cannot determine if it is a PMC, NuGet, Powershell or Windows problem.
Two more error messages appear relating to similar problems in EntityFramework.psm1 and seem to be related to this first problem.
Please can anyone advise the likely cause and guide me through what/how to test and solve this?
I realize this is an old thread, but I just ran into this problem using a newly-installed copy of Microsoft Visual Studio 2015 Enterprise with Update 1.
My solution was to delete this folder:
C:\Users\\(my user ID)\\.nuget\packages\EntityFramework\6.1.3
and allow it to be regenerated the next time the Entity Framework is added to a project. Originally, the PowerShell DLL's were missing from this folder. Strange.
Your question has several parts.
First, you cannot find the documentation, and you have it at your fingertips:
Update-Database -?
Then, you can read at the bottom of this help:
TO see the examples, type: "get-help Update-Database -examples".
For more information, type: "get-help Update-Database -detailed".
For technical information, type: "get-help Update-Database -full".
Second, -StartupProjectName is required to find the configuration file that has the required connection string (you also specify the connection directly using another options) NOTE: This has nothing to do with the solution's startup project
And, if having this clear doesn't solve the problem, try uninstalling and reinstalling the EntityFramework package (in case something went wrong). Take into account that, if you have several projects, it's possible that you need to do this for all the affected projects. You can do this more easily using the Manage Nuget Packages for Solution... menu option.
Edit
(Added to help choose the right Default project in Package Manager Console or specify -ProjectName).
I forgot to answer the most important part of the question: for Migrations commands to work, it's necessary to run them on a project that references the EF assemblies. This solves the missing assembly problem.
In this case it's clear that the chosen StartUpProject, which is the Web App have the connection strings, but doesn't have a reference to EF. That's why running the command fails. And most probably the command is being run with this as the default project in the console.
To solve this, you need to run Migrations within a project which has references to EF, and it will work flawlessly: choose that project in the drop down list named "Default project" on the top bar of the Package Manager Console.
This can also be done by specifying the -ProjectName option, which must point to the project containing the Migration configuration class, and thus, have also the reference to EF. NOTE: you must also sepcify the -ConfigurationTypeName param if you have several migrations for several contexts, as supported from EF 6.
Is there a way to make a simple installer that includes the necessary runtimes and dependency packages, and creates an icon in the OpenSuse menu, so the application will "just work?"
The actual application is just an executable (.EXE) and a handful of support files (mostly XML and CSV).
I already have the application successfully building and executing in MonoDevelop 2.0.
I originally tried to install the Mono Runtime via zypper from the following repository http://ftp.novell.com/pub/mono/download-stable/openSUSE_11.0, but quickly got bogged down in missing package dependencies.
This is what happens when I try to use zypper to install the Mono runtime:
linux-lkfu:~ # zypper addrepo http://ftp.novell.com/pub/mono/download-stable/SLE_11 mono-stable
Adding repository 'mono-stable' [done]
Repository 'mono-stable' successfully added
Enabled: Yes
Autorefresh: No
URI: http://ftp.novell.com/pub/mono/download-stable/SLE_11
linux-lkfu:~ # zypper refresh --repo mono-stable
Retrieving repository 'mono-stable' metadata [done]
Building repository 'mono-stable' cache [done]
Specified repositories have been refreshed.
linux-lkfu:~ # zypper dist-upgrade --repo mono-stable
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Nothing to do.
linux-lkfu:~ #
Notice the last line before the prompt that says "Nothing to do." I don't think it's doing anything.
One option is to buy mono support for SLES 11 from Novell. That will grant you a tested, supported and working mono repository.
If not you have to use the SLES repositories. For mono it's http://ftp.novell.com/pub/mono/download-stable/SLE_11
This should do it:
zypper addrepo http://ftp.novell.com/pub/mono/download-stable/SLE_11 mono-stable
zypper refresh --repo mono-stable
zypper dist-upgrade --repo mono-stable
If you have Visual Studio, you can try Mono Tools for Visual Studio, which provides tooling to make this easy. It is fully functional for 30 days.
http://go-mono.com/monotools/
that depends on how you plan to package them up. Either you manually create (deb for Debian and Ubuntu, rpm for Fedora and openSUSE, or anything else).
Personally, I think at first it is acceptable to simply add a .sh to your ZIP package and ask the end users to execute it for dependency checking, installing, and so on.
Then you can learn about the packaging methods.