I'm looking to work on an application, an internal toolbelt if you will.
Rather than having users messing around with DLL's for the differing tools (they plug in via MEF) I was wondering if it's possible to jump on the back of Nuget?
I'd build the tools, package them as nuget packages and host them internally and the toolbelt application would then query the catalog, retrieve and extract etc etc.
Does anybody know of a way this is possible?
Chocolatey uses nuget as an underlying package manager to install applications on your pc.
http://chocolatey.org/
So I'm sure it's possible, but I've not done it myself.
The nuget documentation discusses a command line and power shell reference: http://docs.nuget.org/
Also linqpad, does something similar (in the paid for version), where you can include dll's from nuget. There is a screen shot on this page: http://www.linqpad.net/purchase.aspx
Related
My company uses the built in TeamCity NuGet repo to create custom NuGet packages that often depend on each other. When I, say, update a .cs page in a custom parent package I'd like for those changes to propagate to all of our packages that are dependent packages of the parent - I believe I can accomplish this using a NuGet installer to "update packages".
My fear is that while I know I can force this update upon all our packages, I want to find a way to exclude anything that isn't hosted on our company repo (which should also mean anything that is hosted on the NuGet.org repo), so anything that we are using from an outside source isn't lumped into this NuGet update.
Preferably, I'd like to know if there's a way to handle this in the our .nuspec for each of our packages (though it seems wildcards don't accomplish this). Any insight to my problem here?
Honestly, it sounds a bit like you're trying to re-create the project reference experience with NuGet packages. If it's at all reasonable to do so, perhaps your best option would be to have all projects in a single solution and use project references instead.
If you're able to migrate your projects to SDK style projects (used by .NET Core, but you can still target the .NET Framework), then you can use dotnet list package or the dotnet-outdated tool. dotnet list package --outdated has an option to specify a list of sources to use. Perhaps if you only specify your private feed it may only search that one. Otherwise the script you create to do all this will need to overwrite the nuget.config file to remove other sources (like nuget.org) when running the command to get your desired output. Then you parse the output and when it finds an update, it modifies the relevant file(s).
I need to create a class library as an API wrapper. The library will be referenced by applications across the enterprise. All of the projects for the enterprise are hosted on VSTS. I'm assuming that the modern architecture approach is to host this new API wrapper class library as a NuGet package and then let each application add a reference to it. Is this correct? Can you please provide a url reference which describes the latest and greatest way to set this up? I'm seeing different approaches described in google search results.
Also, I think the VSTS "Package Management" extension is the preferred approach for hosting internal NuGet packages but I think there's a way to host a package on a shared network drive. Can you please provide a url reference which describes how to do this? Are there any caveats or pitfalls with hosting a NuGet package on a shared drive as opposed to using the VSTS "Package Management" extension? I think the "Package Management" extension is the preferred approach but my manager wants me to experiment with the no-additional cost option of hosting NuGet packages on a shared network drive first.
For your questions:
I'm assuming that the modern architecture approach is to host this new
API wrapper class library as a NuGet package and then let each
application add a reference to it. Is this correct? Can you please
provide a url reference which describes the latest and greatest way to
set this up? I'm seeing different approaches described in google
search results.
Yes, manage the class library as nuget package is the most common way for this situation.
And there is no such document to summary different methods together.
Except manage the class library as a nuget package, you can also add the dlls, of the source code of the class library for other applications, but NuGet package is more efficient.
Can you please provide a url reference which describes how to do this?
Are there any caveats or pitfalls with hosting a NuGet package on a
shared drive as opposed to using the VSTS "Package Management"
extension?
To manage nuget packages in VSTS, you can refer the document Get started with NuGet.
To manage nuget packages in shared network, you can refer Setting up Local NuGet feeds.
The only thing you need to notice is the access permission. If all the works are done inside the shared networt, then manage nuget packages in the shared network is ok. Else, if the nuget packages may be used outside of the shared network (such as use Hosted agent to build applications in VSTS), you'd better manage the nuget packages in VSTS feed.
First of all, I would like to clarify that I'm coming from a Java/Maven background.
I am managing Nexus and we have a team that are developing in .NET who are asking whether they can store exe files in Nexus under a Nuget repository. As this is not possible (and exe-s are not really artifacts as in "archives"), are Nuget packages a reasonable place to store exe-s? I would personally say "no", as, in my opinion, Nuget packages are supposed to just contain libraries and other resources, but as I'm not a .NET developer myself, I'd like to find out what the best practices are.
are Nuget packages a reasonable place to store exe-s?
If it's a tool, then yes. There are several good examples where Nuget is an excellent place to store exe-files.
For example:
The nuget package dotless has a tool (standalone exe), which is a compiler for CSS-files. This enables us to use that tool in our (TFS-) build server without installing any third party software on the build server.
But other than that, I agree with you. A Nuget-package is mainly for libraries and other resources that will be references in the project. But it's after all just a platform for spreading code between developers and different teams.
Or as Nuget puts it:
No matter what your package does or what code it contains, NuGet is
how you package that functionality into a component that can be shared
with and used by any number of other developers.
If the purpose of your nuget package is to deploy an executable program, then sure you can store an exe in there - what other option is there after all!
Since a recent update of Nuget Package Manager (from 2.9 to 3.2.0 I guess), installing package via nuget doesn't add addition files of the package anymore. It just adds the libraries only, update the "project.json" and something like that.
For example: Installing MVVMLight to a project will add Models, ViewModels and Views folder to project. Also, it will add a MainViewModel.cs, ViewModelLocator.cs to ViewModels folder. Now none of these files/folders are added to project.
Any suggestion will help
Since Nuget 3.1 this is no longer supported: https://docs.nuget.org/release-notes/nuget-3.1. One of the main reasons is that packages can copy in files on install, but you're not sure what to do with it on uninstall (as content might have changed manually). But do note that there's an open issue to maybe re-enable this functionality.
Laurent Bugnion of MVVM Light is aware of this issue as well:
Caution: Full package in Windows 10 Universal applications (UWP)
There is a known issue when you install the “mvvmlight” package in
Windows 10 universal applications. The Nuget team unfortunately
changed the way that Nuget works for this framework, and it doesn’t
allow installing additional files, or running scripts anymore. Because
of this, installing the “mvvmlight” package in Windows 10 UWP
applications creates the exact same result as installing the
“mvvmlightlibs” package. Because running a script is not allowed, it
is not even possible to warn the user.
I will publish more detailed information on how to add the scaffolding
to a Windows 10 UWP application manually. Stay tuned.
As of today, he didn't post a full guide yet, but you could try to run the packaged powershell script manually.
At my work place, we are not allowed to install packages from Nuget, so I am just wondering is there any place to download installer instead, so an internal packaging team can distribute it across the firm.
And is the package production ready?
Unfortunately, Microsoft.Bcl.Async is only distributed via NuGet. You would need to use the package manager to get the assemblies, though you could then just copy the assemblies manually into your system.
And is the package production ready?
Yes, it is now production ready. The BCL Team just announced that this package is now considered Stable. From their post:
Being stable means the owner of that package states that API and functionality are unlikely to change and therefore suitable for use in production.
You could just download the package from another PC (out of work) and then copy the assemblies. Of course you don't get the extra benefits from NuGet, but it's still a viable option.
EDIT Just saw that a few days ago the package was declared stable as Reed correctly indicated.