X-Received: by 2002:a05:622a:14d0:b0:421:c458:1733 with SMTP id u16-20020a05622a14d000b00421c4581733mr2128038qtx.7.1704074952790; Sun, 31 Dec 2023 18:09:12 -0800 (PST) X-Received: by 2002:a05:690c:c8a:b0:5e8:c4b6:9b5a with SMTP id cm10-20020a05690c0c8a00b005e8c4b69b5amr6258387ywb.4.1704074952481; Sun, 31 Dec 2023 18:09:12 -0800 (PST) Path: csiph.com!1.us.feeder.erje.net!feeder.erje.net!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.basic.visual.misc Date: Sun, 31 Dec 2023 18:09:12 -0800 (PST) Injection-Info: google-groups.googlegroups.com; posting-host=2a0b:2fc0:2d5a:98c1:8d6a:d76b:a871:1117; posting-account=XhTMzQoAAADbavTSGmRv9jzNWXM034O_ NNTP-Posting-Host: 2a0b:2fc0:2d5a:98c1:8d6a:d76b:a871:1117 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1caf760d-bee2-4ad6-a86c-6450b7dfc419n@googlegroups.com> Subject: .net Core Tools Download From: Manila Ursua Injection-Date: Mon, 01 Jan 2024 02:09:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lines: 223 Xref: csiph.com comp.lang.basic.visual.misc:3549 The .NET CLI uses manifest files to keep track of tools that are installed = as local to a directory. When the manifest file is saved in the root direct= ory of a source code repository, a contributor can clone the repository and= invoke a single .NET CLI command to install all of the tools listed in the= manifest files. This command creates a manifest file named dotnet-tools.json under the .con= fig directory. To add a local tool to the manifest file, use the dotnet too= l install command and omit the --global and --tool-path options, as shown i= n the following example: .net core tools download Download Zip https://t.co/X8aPPL6JJK=20 You typically add a local tool to the root directory of the repository. Aft= er you check in the manifest file to the repository, developers who check o= ut code from the repository get the latest manifest file. To install all of= the tools listed in the manifest file, they run the dotnet tool restore co= mmand: The command that you use to invoke a tool might be different from the name = of the package that you install. To display all of the tools currently inst= alled on the machine for the current user, use the dotnet tool list command= : .NET Core 1.0.4 and .NET Core 1.1.1 were also released today. Both releases= include a set of reliability updates to improve the quality of .NET Core. = You can download the .NET Core Runtime releases via our .NET Core Runtimes = download page. If you are looking for the .NET Core SDK to get the latest t= ools, try the .NET Core SDK download page. You should use the ASP.NET Core template if you want to build web sites or = services, use the .NET Core template for tools or .NET Core experimentation= and use the .NET Standard (Class Library) templates for libraries that you= want to use with multiple apps of different application types (for example= , .NET Core, .NET Framework and Xamarin). There are also platform-specific = class library templates (for example, .NET Core (Class Library) and .NET Fr= amework (Class Library)) that enable you want to take advantage of APIs ava= ilable in those respective platforms and not in .NET Standard. There are two experiences for migrating project.json projects. You can migr= ate project.json files on the command-line, with the dotnet migrate command= . The command will produce a .csproj project file that you can use with the= latest .NET Core tools or open in Visual Studio 2017. You can also open .xproj files in Visual Studio 2017. Visual Studio will mi= grate your .xproj files for you, producing a .csproj file that you can use = going forward for use with both Visual Studio 2017 and with the latest .NET= Core tools at the command-line. Thanks to everyone that helped to get .NET Core Tools to 1.0. There are so = many people to thank that helped the product get to today and we thank you = for your patience as we iterated on our tools. We hope that you are happy w= ith the product, specifically the 1.0 tools. Sincerely, thank you! One of the exciting new features in .NET Core 2.1 are Global Tools. Global = Tools provide the ability to distribute command line tools via a NuGet pack= age and install them with the dotnet command line. Before Global Tools were= released, .NET Core had the concept of project tools, which were tied to a= specific project by referencing the NuGet package in the project file. To share the deployment features we had for AWS Lambda, AWS Elastic Beansta= lk, and Amazon Elastic Container Service (Amazon ECS) from the AWS Toolkit = for Visual Studio, we created project tools for each of the services. For e= xample, the same Lambda deployment feature that is available in the AWS Too= lkit for Visual Studio can be executed from the command line like this. Now with Global Tools being the new preferred tooling distribution for .NET= Core, we have converted our project tools to be Global Tools. One of the b= iggest benefits this change provides is the ability to use these tools with= out needing any project source. This makes it easy to use these tools in re= lease pipelines. NuGet is the distribution mechanism for both Global Tools and project tools= , but a NuGet package cannot support both a Global Tool and a project tool = in the same NuGet package. To distinguish which version of these packages i= s a Global Tool, the version number for each of these packages has been bum= ped to 3.0.0.0. Versions numbers earlier than 3.0.0.0 are older project too= ls. We highly recommend that you migrate to the Global Tools version becaus= e going forward, that is where we plan to do our development. All of these tools are open source and can be found in their GitHub reposit= ory. If you have never used these tools, they can be excellent for automati= ng your deployments or working with .NET Core Lambda outside of Visual Stud= io. The reason why dotnet tool list is not working is that that command will on= ly show the tools installed in the current directory. In order to show all = the globally installed tools you have to execute the command dotnet tool li= st --global. Regarding the Johan B's comment, which states ef tools cannot be used with = class libraries for now, it is partly addressed by using --startup-project = workaround, for example: dotnet ef --startup-project ../ProjectThatCanRunCo= mmand/ migrations add InitDb, more info: Parameterize directories used by d= otnet-ef. Starting with .NET Core 2.1, Microsoft introduced the .NET Core Tools platf= orm as part of the .NET Core SDK and since then, these tools have become a = vital, although underutilized part of the .NET ecosystem. .NET Core Tools a= re a simple way to create, publish, and consume what are essentially .NET C= ore applications that can be published and shared using the existing NuGet = infrastructure for packaging and distribution. This means it's quick and ea= sy to build tools that you can share either publicly with the world or priv= ately with yourself or your onsite team. Although the original idea was to build tools to aid as part of the build a= nd development process, this platform really offers a much wider scope beca= use you can publish and share any .NET Core executable application. This in= cludes servers that run full ASP.NET Core applications or services and even= .NET Core desktop applications. .NET Core Tools can be installed either as a global or local tool. Global t= ools are installed in a central location on the local computer and mapped o= n the global path, so they are globally accessible. Local tools are install= ed into a specific folder and only accessible from there. They're essential= ly project-specific and they-re useful for build systems that need to encap= sulate tools as part of a build process or Continuous Integration (CI). In this article, I focus on the usage for global tools and the sharing aspe= cts of .NET Core Tools as general-purpose utilities using the global -g com= mand line switch. Everything except the install location and global path ac= cess also applies to local tools in the examples. Because .NET Core Tools are executables installed from a remote source and = because there's no validation process for published tools, it's important t= o understand that there is a potential security risk to your computer. The = code that comes down can execute locally on your system and has access to y= our local resources when you run the tool. If all this looks familiar from Node,js and NPM - you're right. The idea of= shared tools isn't new by any means and follows various other development = platforms and their package managers. But for .NET to easily publish and sh= are binary executable tools in a cross-platform manner is relatively new an= d opens up the reach of small and useful tools that otherwise would never b= e shared. Although .NET Core Tools were initially designed to provide development tim= e helper tools, they're just plain .NET Core executables that can do anythi= ng that a .NET Core executable can do. This means you can use it for all so= rts of things that might not be directly developer related. One of the reasons that .NET Core Tools aren't so widely used that it's not= that easy to find them. Until very recently, you weren't even able to sear= ch the NuGet Site specifically for tools but that was recently fixed with n= ew search filters. A fully self-contained application is useful and sometimes required. If you= 're building an end user tool or application, a self-contained application = that has everything it needs included is usually a better call. But if you'= re building developer tools, the lightweight and universal .NET Core Tool d= istribution experience is often preferable. The list shows both the Package Id, which is the install name used with NuG= et, and the Command name, which is used to run the package. Package ID and = Command can be different, as demonstrated by the dotnet-magicwindball ID an= d the magicwindball command. But they don't have to be different. For examp= le, my LiveReloadServer package uses the same name for the package ID and c= ommand name. The dotnet- prefix is an original convention used by various .= NET internal tools to make it obvious that they're .NET tools, but that con= vention is discouraged now. Generally, it's better to use the same name for= the package ID and command and to use the most descriptive name possible. To bring home the utility of .NET Core Tools, I'd like to describe a few of= the .NET Core Tools I've created and discuss the hows and whys of creating= them. I've been huge fan of these tools because it's so frictionless to pu= blish a tool for easy reuse. If it weren't for the ease of sharing via NuGe= t, I probably wouldn't have bothered sharing these tools at all. Some of these tools I built mainly for myself, but because I've made them p= ublic, they ended up getting used by quite a few other people. Maybe you'll= find some of these useful as well. But more importantly, I hope it inspire= s you to share your own tools no matter how silly or simple - somebody else= might find them useful too! The first couple of examples are your typical utility tools that, under nor= mal circumstances, I would have distributed as a downloadable installer or = just a standalone binary. If a tool is popular enough, I still go that rout= e in addition to the .NET Core Tool, but I tend to use the .NET Core Tool r= ather than a standalone installed application. 35fe9a5643