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!
Related
A few of our NuGet packages, in a framework we use for our ASP.NET MVC sites, reference binaries EVOPdf / EVOPDFtoHTML to be exact that I'd rather not have hard pathed on our build machine. The specific versions we are using are not found on nuget.org any more, so we are forced to hold onto the .dll's ourselves.
The solution I have come to involves housing those binaries in source control, and building them as an in-house NuGet package to be distributed to the other packages that need them; while this works, and though it eliminates hard-pathed references, it goes against standard practice to house binaries in source control.
Because I am one of the few who access this NuGet framework (and the wonders of VSTS) I am not too worried about slowing down our branch splitting/merging times but I am still wondering if there is a more practical way to accomplish this.
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.
I'm very confused about Syncfusion Essential Studio. I want to use the XlsIo package in my app to extract some data from an Excel file and I don't understand how I should reference it.
The preferred way would be to use NuGet packages, for I which I suppose I could use the WPF nuget URL? Apparently no license key must be provided anymore to use it, which makes me wonder when I have to provide it – and why I installed a whopping 3GB tool if I could have just used this public NuGet package URL instead?
I did not install assemblies to the GAC as I plan to work on multiple devices with multiple projects and don't want to rely on assemblies being in the GAC, if possible.
I guess I can also just reference the assemblies in the essential studio install directory, but I'm not sure whether that's intended and how I'll deal with updates (cross-device issue aside).
So what I'm asking is basically: can I just use the NuGet packages, as that would be the easiest and most maintainable option in my opinion, and do I have to provide any license information at some point (e.g. deployment)?
Bonus question: what purpose exactly serves the essential studio, if I end up using NuGet packages? A mere sample viewer + number of optional tools?
Please find the response for your queries.
Query 1: Can I just use the NuGet packages, as that would be the easiest and most maintainable option in my opinion, and do I have to provide any license information at some point (e.g. deployment)?
Answer: Syncfusion is providing license on customer basis only. You no need to worry, if you have license for each developer. You can use any installation option such as Essential Studio installer, Platform installer, Link Installer or NuGet packages.
Query 2: What purpose exactly serves the essential studio, if I end up using NuGet packages? A mere sample viewer + number of optional tools?
Answer: Essential Studio build comprises of all platforms, samples & additional tools/utilities for configuration purpose. This will be helpful for evaluation purpose for the customer who doesn’t know about Syncfusion products.
Online samples are there to showcase our Syncfusion products. But sometimes user want to refer the code snippets and for window client platforms. So, Essential Studio build is necessary for these cases. Syncfusion have separate platform builds also if the customer needs to evaluate the products with specific platforms. To know more about Essential Studio setup features, click the below link.
https://help.syncfusion.com/common/essential-studio/overview
Thanks,
Mathi.
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
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.