Locally installing dotnet tool uses old command name - c#

I've followed the tutorials to create a dotnet tool and install it locally. After I was satisfied, I tried changing the name of the command from botsay to something-else. Unfortunately it always installs with the command name botsay. Even if I run dotnet tool uninstall, delete the project, and start over, it keeps using the name from the tutorial. The only way I can change it is by changing the project name to something else. Why does it use the old command name and how can I change it?
The directory structure is:
sources
--My.Project.Name
----nupkg
------My.Project.Name.1.0.0.nupkg
--.config
----dotnet-tools.json
My csproj is:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<PackAsTool>true</PackAsTool>
<ToolCommandName>something-else</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>
</PropertyGroup>
</Project>
And the dotnet-tools.json is:
{
"version": 1,
"isRoot": true,
"tools": {
"my-project-name": {
"version": "1.0.0",
"commands": [
"botsay" <--- I want this to be "something-else"
]
}
}
}

OK, found the answer. The package was being installed from a cache. I had tried supplying the --no-cache argument to dotnet tool install, but it didn't make a difference. The solution is:
run nuget locals all -List
find the cached package in one of these locations
delete it

Related

Azure Pipeline: dotnet publish fails - assets.json doesn't have a target for '.NETCoreApp,Version=v3.1/win-x64'

I have a .NetCore 3.1 commandline app. When buidling locally and publishing, it works completely fine using below commandline
dotnet publish -c dev -r win-x64 --self-contained true
In the Azure pipeline - I had to do the dotnet restore before doing a publish using the above command. Whilst publishing I had to add extra param --no-restore, as per Microsoft's recommendation here as I have private nuget feeds.
dotnet publish -c dev -r win-x64 --self-contained true --no-restore
Most dotnet commands, including build, publish, and test include an
implicit restore step. This will fail against authenticated feeds,
even if you ran a successful dotnet restore in an earlier step,
because the earlier step will have cleaned up the credentials it used.
To fix this issue, add the --no-restore flag to the Arguments textbox.
Now, the publish part of the pipeline has started failing with the error -
C:\Program Files\dotnet\sdk\3.1.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file 'MyProject\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v3.1/win-x64'. Ensure that restore has run and that you have included 'netcoreapp3.1' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.
Am not using a publish xml, but specifying all the arguments as shown above in the command line. I've checked the csproj has the target framework specified
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<Configurations>Debug;Release;dev;test;pre;prod</Configurations>
</PropertyGroup>
Need any pointers as to what might be going wrong here?
Thanks
Please add RuntimeIdentifier as mentioned in the error message:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<Configurations>Debug;Release;dev;test;pre;prod</Configurations>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
Please also check PlatformTarget.
<PlatformTarget>AnyCPU</PlatformTarget>
I guess the local machine has a different OS than the build agent.

Creating new blazor application throws an error when run

I am following Get started with Blazor. I have created the application and attempt to run it as is i have made no changes.
There are three things in my event log.
The directory specified for caching compressed content C:\inetpub\temp\IIS Temporary Compressed Files\Clr4IntegratedAppPool is invalid. Static compression is being disabled.
Application 'MACHINE/WEBROOT/APPHOST/WEBAPPLICATION1' with physical root 'C:\Users\LindaL\source\repos\Daimto.RazorTest.Tools\WebApplication1\' failed to start process with commandline 'c:\program files (x86)\microsoft visual studio\2017\professional\common7\ide\extensions\microsoft\web tools\projectsystem\VSIISExeLauncher.exe -argFile "C:\Users\LindaL\AppData\Local\Temp\tmpF272.tmp"', ErrorCode = '0x80004005' : 0.
Application 'MACHINE/WEBROOT/APPHOST/WEBAPPLICATION1' with physical root 'C:\Users\LindaL\source\repos\Daimto.RazorTest.Tools\WebApplication1\' failed to start process with commandline 'c:\program files (x86)\microsoft visual studio\2017\professional\common7\ide\extensions\microsoft\web tools\projectsystem\VSIISExeLauncher.exe -argFile "C:\Users\LindaL\AppData\Local\Temp\tmpF272.tmp"', ErrorCode = '0x80004005' : 0.
Note i just update to visual studio professional 2017 15.9.3. I have used blazor before this was working fine.
Update: This appears only in the "Blazor" project type.
Update2: hitting Cntrl-F5 as opposed to just F5 – No change.
Update3 Project file per request in comment in answer below
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<RunCommand>dotnet</RunCommand>
<RunArguments>blazor serve</RunArguments>
<LangVersion>7.3</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Blazor.Browser" Version="0.6.0" />
<PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.6.0" PrivateAssets="all" />
<DotNetCliToolReference Include="Microsoft.AspNetCore.Blazor.Cli" Version="0.6.0" />
</ItemGroup>
</Project>
Delete global.json and see if that helps.
https://github.com/aspnet/Blazor/issues/1342
If that doesn't help try adding global.json with content
{
"sdk": {
"version": "2.1.500"
}
}
If all fails, close all Visual Studio instances and reinstall Blazor templates with dotnet new -i Microsoft.AspNetCore.Blazor.Templates and create new Blazor solution with dotnet new and use Blazor template you want.

dotnet watch $(SolutionDir) is *Undefined*

I'm trying to use dotnet watch however my project references nuget package which uses $(SolutionDir) to copy some files in prebuild event. It kinda make sense because dotnet watch is run on project level so $(SolutionDir) doesn't exist. Is there any way to run dotnet watch for entire solution?
I created a batch script watch.bat
call SET ASPNETCORE_ENVIRONMENT=Development
call SET SolutionDir=%~dp0\\..\\..\\
call dotnet watch run
Added a script in package.json:
"scripts": { "dotnetwatch": "watch.bat" }
Now I can run it like this from CLI:
npm run dotnetwatch
or from within visual studio with the following launchsettings.json profile:
"dotnet watch": {
"executablePath": "watch",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
It's not an ideal solution but at least it's good enough for me.
As of dotnet-watch 2.0.0-preview2, it is not possible to run dotnet watch on solution files. However, you can construct a custom 'project' for the watcher that will watch multiple projects. See https://github.com/aspnet/DotNetTools/tree/rel/2.0.0-preview2/samples/dotnet-watch/WatchMultipleProjects for a complete sample of how to do this.

How to run .net console application (built on windows) on Linux using .net core [duplicate]

I have a simple .NET Core project (console app) that I'm trying to compile and run. dotnet build succeeds, but I get the following error when I do dotnet run:
dotnet run
Project RazorPrecompiler (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in [path].
My project.json looks like this:
{
"buildOptions": {
"warningsAsErrors": true
},
"dependencies": {
"Microsoft.AspNetCore.Razor": "1.0.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"description": "Precompiles Razor views.",
"frameworks": {
"netcoreapp1.0": {
"imports": [ ]
}
},
"version": "1.2.0"
}
What is hostpolicy.dll, and why is it missing?
Update for dotnet core 2.0 and beyond: the file appname.runtimeconfig.json (for both debug and release configuration) is needed in the same path as appname.dll.
It contains:
{
"runtimeOptions": {
"tfm": "netcoreapp2.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.0.0"
}
}
}
then dotnet.exe exec "path/to/appname.dll" [appargs] works.
This error message is unhelpful. The actual problem is a missing emitEntryPoint property:
"buildOptions": {
...
"emitEntryPoint": true
},
Once this is added, the compiler will let you know about any other problems (like a missing static void Main() method). Successfully compiling the project will result in an output that dotnet run can execute.
If I'm not mistaken, one scenario when you can hit the issue is this: You have an integration project that references another application project (not library). In this case, dependentProject.runtimeconfig.json won't be copied to your integration project's output folder and you won't be able to run dependentProject.exe binary because it will throw The library hostpolicy.dll was not found..
There is a Github issue for this and a workaround.
Edit: Should be fixed in .NET SDK 5.0.200.
I had similar problem running tests in VS19.
========== Starting test run ==========
Testhost process exited with error: A fatal error was encountered. The
library 'hostpolicy.dll' required to execute the application was not
found in 'C:\Program Files\dotnet'. Failed to run as a self-contained
app.
After digging into it I found the source of the problem:
The full path the the .runtimeconfig.json in the test binary folder was above 255 characters. Renaming the module, so the file path becomes shorter, resolved the problem.
This occurred when a Visual Studio 2019 preview upgrade .Net Core to the latest preview (specifically .Net Core 3.1.100-preview2-014569).
Reinstalling/repairing .Net Core 3.0.100 solved the problem for me.
I'm not sure why but I ran in to the problem when executing the .exe file in my \bin folder while the .exe in my \obj folder works fine.
I am having this problem in Dotnet Core 3.1 Console application.
If you are publishing your application, make sure that your target runtime set to the specific runtime that you had installed in your target machine.
If you set to portable it will pick whatever runtime that it feels comfortable (which you might not have it installed)
I had this happen with .NET 6.0 where somehow the appname.runtimeconfig.dev.json file was not being generated in the bin/Debug/net6.0/ directory.
The fix was modifying the .csproj file and include this fragment inside the <PropertyGroup> element:
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
I found this solution while searching with https://www.google.com/search?q=net60+runtimeconfig.dev.json at Breaking change: runtimeconfig.dev.json file not generated - .NET | Microsoft Learn with the solution at MSBuild properties for Microsoft.NET.Sdk - .NET | Microsoft Learn:
GenerateRuntimeConfigDevFile
Starting with the .NET 6 SDK, the [Appname].runtimesettings.dev.json file is no longer generated by default at compile time. If you still want this file to be generated, set the GenerateRuntimeConfigDevFile property to true.
<PropertyGroup>
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
</PropertyGroup>
After applying this to the .csproj file and re-building the project, debugging from Visual Studio Code worked fine including stopping at the breakpoints that I had set previously.
For me the issue was with the version mismatch. I had a different ".Net core SDK" version installed and a different version was specified in .json file.
Once I modified the version in my .json file the application started working fine.
In my case it was because I was publishing a self-contained application for the wrong target. My intent was to run on alpine linux, but I was building for libc when I should have been building for musl.
The failing package was built using:
dotnet publish --self-contained true --runtime linux-x64 --framework netcoreapp2.1 --output /app
Changing the RID:
dotnet publish --self-contained true --runtime linux-musl-x64 --framework netcoreapp2.1 --output /app
produced a functional package. Notice the RID changed from linux-x64 to linux-musl-x64. If I had read the .NET Core RID Catalog page this could have been avoided. 😅
Maybe you didn't want to do a "Console .Net Core" project but a "Console .Net Framework" project. It solves the problem, for me...
My problem was that I have 2 .NET Core App projects and one is dependent on the other.
(so I can then execute that application from that other application)
But .NET Core applications (with default config) need <assembly name>.runtimeconfig.json file (to get some launch config) which isn't copied by default.
The only solution that worked for me was adding to Project Properties > Build Events (of the dependent project) this command:
COPY "$(SolutionDir)<dependency name>\$(OutDir)<dependency assymbly name>.runtimeconfig.json" "$(SolutionDir)$(ProjectName)\$(OutDir)" /Y
But you can also copy the <dependency assembly name>.runtimeconfig.json file by hand to the dependent project.
Note that there should be a better more generic way to do this for every .NET Core App Project automatically.
This error is quite generic. So the real problem can be anything.
In my case (if helps anyone with same issue), I created a Class Library project instead of a Console Application project.
A Class Library DLL can't be runned with MSBuild, even if it has a Main method.
Only Console Application DDL can be runned as dotnet <appname>.dll
I was getting similar error while running Unit tests using VSTest#2 task in Azure Devops.
In my case, the problem was with my testAssemblyVer2 value. I was giving wrong pattern for test dlls.
Below one worked for me.(if you are getting this error with VSTest)
- task: VSTest#2
displayName: 'Running UnitTests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
$(System.DefaultWorkingDirectory)\SrcFolder\BBBB.UnitTests\**\bin\**\*.BBBB.UnitTests.dll
$(System.DefaultWorkingDirectory)\SrcFolder\AAAAa.UnitTests\**\bin\**\*.AAAA.UnitTests.dll
!**\*TestAdapter.dll
!**\obj\**
platform: x64
configuration: Debug
codeCoverageEnabled: true
So try to give correct pattern value for testAssemblyVer2 input. Make sure its filtering only the required dlls.
I had this same problem with a .NET Core 3.0 WPF app, but I found that my app wouldn't run in Visual Studio 2019 either.
I discovered on the project properties page (right-click on project > Properties) that the Target framework was set to .NET Core 3.0.
I'd recently updated VS 2019 which had also installed .NET Core 3.1, so I switched to that in the dropdown, and it worked again.
(I also had to update my shortcut to point to the netcoreapp3.1 folder instead of the previous netcoreapp3.0 folder.)
Promoting voltrevo's comment as an answer as I believe this should be the most common case of the problem. When you build your solution, sometimes you might get 2 directories with outputs bin and obj. 'Bin' directory has everything that is needed to run dotnet.exe command. Just run from the bin directory and things should be good. :)
For me with ASP.NET Core 2.0 on Azure, it was the appname.deps.json that did the trick. You need to copy it from your build directory to Azure.
For me, the error occurred during the SonarQube coverage scan due to one of the projects had a project reference to a MSTest project.
I faced this problem and it took me couple of days to figure out the solution.
Go to Visual Studio Installer.
Click on 'More' option of the Visual Studio.
Select 'Repair'.
It'll take some time for the download and installation.
Once it's completed restart the machine and try again.
This should solve the issue.
Add the OutputType on the PropertyGroup and issue is solved
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
more about this MSBuild can be found here

No executables found matching command 'dotnet-aspnet-codegenerator'"

When trying to add a Controller in an ASP.NET Core project using Visual Studio 15 Enterprise with Update 3, I get the error below:
"The was an error running the selected code generator: No executables found matching command 'dotnet-aspnet-codegenerator'"
If you're using csproj (Visual Studio 2017) instead of project.json, then you need to add the following to your csproj file:
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.1" />
</ItemGroup>
If you are using Mac (OS X) or any supported distribution of Linux, you have to run:
dotnet tool install --global dotnet-aspnet-codegenerator --version 2.2.3
Additionally, on Mac I added to my .zshrc (or bash equivalent)
export PATH=$HOME/.dotnet/tools:$PATH
And I had to make sure to restart Terminal.
For the latest version, in project.json add the following under dependencies:
"Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
"version": "1.1.0-preview4-final",
"type": "build"
},
"Microsoft.VisualStudio.Web.CodeGenerators.Mvc": {
"type": "build",
"version": "1.1.0-preview4-final"
}
and the following under tools:
"Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
"version": "1.1.0-preview4-final",
"imports": [
"portable-net45+win8"
]
}
A more robust answer than copying version numbers into your configuration file is to use NuGet to ensure that the packages are added to your project.
Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution.
First, get everything up to date. Choose the Updates tab. Check the box for Update All and run this a few times. Don't be surprised if some stuff downgrades the first couple of times you run the upgrade. Some dependencies seem to have to be handled sequentially. It took me about 5 upgrades to get everything up to date.
Then, in the browse tab, search for CodeGeneration.Tools. Install it. Do the same for CodeGenerators.Mvc. As you find additional error messages, you should be able to find any missing packages in NuGet.
In dotnet core 2.1.1 you'd expect that the situation has changed and you may not need to add much. I'm sorry to annoy you but the situation is same and all you need to do now is update your version of the tool or package you wish to use.
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.4" />
</ItemGroup>
This worked for me. I hope it works for eveyone else that gets stuck here. Note that the key reference is DotNetCliToolReference not PackageReference
Add the following to your project.json:
Under dependencies:
"Microsoft.VisualStudio.Web.CodeGenerators.Mvc": {
"version": "1.0.0-preview2-final",
"type": "build"
}
Under tools:
"Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
"version": "1.0.0-preview2-final",
"imports": [
"portable-net45+win8"
]
}
Version number may change depending on which version of .NET Core you're using in your project
You may get another error about Microsoft.DotNet.InternalAbstractions missing, in which case you'll need to get from NuGet
Make sure "Microsoft.VisualStudio.Web.CodeGeneration.Tools" version in dependencies matches "Microsoft.VisualStudio.Web.CodeGeneration.Tools" version in tools
I had to add the following to my CSProj file:
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
<DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="1.0.0-msbuild3-final" />
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
</ItemGroup>
After adding that I installed CodeGenerators.Mvc with nuget package manager.
I was still getting an error saying it can't find some file in the MCD folder so I had to copy and paste the entire bin\Debug\netcoreapp1.1 folder into bin\MCD\Debug\netcoreapp1.1
I ran the scaffolding and it worked!
I encountered the same issue in Visual Studio Mac Community Edition 2017. Prior to running the scaffold command from the project directory, make sure the directory has the Program.cs, Startup.cs and .csproj files. if not, then run the command ls-al and then cd into the project directory which would be inside your current project directory and then execute the scaffold command. An obvious mistake many overlook.
Just add tag 'DotNetCliToolReference ' and package code design on .csproj and execute code-generate command on root solution. Thats worked to me.
.csproj
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.3" />
</ItemGroup>
<ItemGroup>
...
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.0.3" />
</ItemGroup>
Command
PS C:\Users\miche\projetos\asp_net_core\crud> dotnet aspnet-codegenerator controller -name ProdutosController -m Produto -dc AppDataContext --relativeFolderPath Controllers --useDefaultLayout --referenceScriptLibraries
Don't forget to build and restore solution after add package ;)
For VS 2015, in project.json file -
under dependencies add -
"Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
"version": "1.0.0-preview2-final",
"imports": [
"portable-net45+win8"
]
},
"Microsoft.VisualStudio.Web.CodeGenerators.Mvc": "1.0.0-preview2-final"
then under tools add-
"Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
"version": "1.0.0-preview2-final",
"imports": [
"portable-net45+win8"
]
}
In Visual Studio Code change your yourproject.csproj
<pre>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.2" PrivateAssets="All" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="2.1.4" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.6" PrivateAssets="All" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.4" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" version= "2.1.0-preview1-final" />
<PackageReference Include="Microsoft.Extensions.SecretManager.Tools" version= "2.0.2" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.4" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.2" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" version="2.1.0-preview1-final" />
</ItemGroup>`enter code here`
</pre>
I just typed in Linux:
~/.dotnet/tools/dotnet-aspnet-codegenerator razorpage -m Movie -dc RazorPagesMovieContext -udl -outDir Pages/Movies --referenceScriptLibraries
So, I did not start with 'dotnet' (my current version: 2.2.300)
I do not like this solution, but it worked.
On Windows 10
In my case the installer added the wrong path to the Path environment variable.
The path added was pointing to a non existing folder under Programs. It needs to point to dotnet-aspnet-codegenerator.exe.
For me the correct path was in my user folder: ~\.dotnet\tools
You can check if the correct path was added by running: echo $env:Path
If the path is missing or incorrect you just need to add the correct path to the Path system environment variable.
You might be able to test this by using PowerShell to set your local variable: $env:Path += ";C:\Users\<YOUR_NAME_HERE>\.dotnet\tools"
But I haven't tried this.
To fix it globally
Start typing Environment in the windows search and you should see the Control panel option to Edit system environment variables.
Click the Environment Variables... button in the lower right corner.
Under System variables find and select the Path variable, then click Edit.
Check if the path to dotnet-aspnet-codegenerator.exe is there and if not click New and add it.
Restart your computer.

Categories

Resources