NuGet.Server | NuGet Server is a lightweight standalone NuGet server | DevOps library
kandi X-RAY | NuGet.Server Summary
kandi X-RAY | NuGet.Server Summary
The home of the NuGet.server package, a lightweight standalone NuGet server.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of NuGet.Server
NuGet.Server Key Features
NuGet.Server Examples and Code Snippets
Community Discussions
Trending Discussions on NuGet.Server
QUESTION
Sorry for the super messy title, I had no clue how to describe the issue in one sentence.
So my current situation. A c# project in Visual studio. This project references a package that I created locally and is not on NuGet or any other repo. Recently changed to having two development machines due to COVID, one at home, one at work. Using git to keep both sides up to date.
Both machines have this package but they are stored on different drives. And as the location of the package is stored in .csproj file whenever I pull a commit that was made on the other machine it will overwrite the location of the package and say it's unable to find it. Which requires me to remove the reference and readd it. Now, this is a hassle to do each time, but I can't exactly exclude .csproj from git.
As I have no clue how to even google for something like this I came here to ask: Is there a smarter way to do this?
Edit Its not my style to post a question and then twiddle my thumbs. Ive come accross NuGet.server to selfhost my package. Dont want to upload it to NuGet itself as its a very case specific package. Is it a good idea to host my private NuGet.server on the webserver I have anyway?
...ANSWER
Answered 2020-Jul-07 at 07:31maybe use an environment variable to indicate the path to this package instead of putting it in .csproj
QUESTION
I'm getting the following error when attempting to install a nuget package into a standard .NET framework 4.7 project:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
I'm using Visual Studio 2017 15.3.3 Enterprise (latest and greatest).
Given that this is my package, I have full control over the source code. The interesting part is that I have used this package in the past with no changes in the name, but for this go round, I rebuilt it to add a feature and am now getting this error.
Even more interesting is that I have packages from the same library, with the same namespace conventions, with longer names, that work just fine and have installed into this same project with no problems at all.
I have already tried shrinking the package name, shrinking the class names within the package itself, cleaning out the build directory, cleaning out the package home from the nuget server (it's a local server with the latest nuget.server installed which otherwise works just fine), and even clearing out the bin directory of the project in question, clearing out ALL the bin directories of ALL the ancestors to the "offending" package, clearing out the package cache, rebooting the computer and rebuilding the entire nuget package chain from scratch, all to no avail. I was told by one of the MS MVP's that "they fixed that". Apparently not.
Any help would be appreciated here, I'm at my wit's end and have run out of ideas to try.
Thanks.
...ANSWER
Answered 2017-Aug-31 at 17:54OK, big Thank You @danmosemsft who suggested digging around with the SysInternals process monitor. After fiddling with it for a bit, I finally figured out how to narrow the result set to just file activity. What I noticed, and the nuget engineers should TAKE NOTE of this: The problem was NOT a too-long project name, rather, nuget was attempting to update a package that was no longer there. Why it went away is a mystery yet to be solved. I normally stay out of the packages directory and do not fuss with the packages.config file. I think that this might have to do with my impatience waiting for VS to start, load all the goodies and then allow me to perform a "Manage NuGet packages" - update all. I remember seeing an update to either NUnit or FluentAssertions that wanted to perform some additional file activity aside from just installing the next version, a script I believe. Can't speak to it with assurance, I wasn't paying that much attention as third party updates usually "just work". I didn't see the "finished" line from NuGet so I think that was the root of my problem. Rather than wait until VS has settled down, I pushed it a bit (hey, the buttons responded so there shouldn't be any problems...).
As a result, the packages directory was absolutely chock full of old stuff that did NOT belong there. So, I manually cleaned up all the cruft, manually cleaned up the packages.config file, restarted VS, waited for it to settle down, performed my NuGet updates and viola! no problem - HAVING NOT CHANGED ANY OF THE ANCESTRAL PACKAGE NAMES BY EVEN A SINGLE CHARACTER.
So, what do I conclude from this? It is my belief, and the guys that actually build nuget and nuget.server should take a closer look at the errors being thrown, such that I think that the error is not so much a path too long error, rather it's a "hey, I didn't find the file I expected so the file name is full of junk (and probably too long now) so I'll throw an error that says it's too long and quit". It's seemingly a failure to handle a missing package/package directory that is causing this particular problem
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved.
Thanks to all of you that responded.
Update: While the above contributed to the solution, it was NOT the answer. Here is the sequence of events that led to this problem and it's ultimate resolution. The solution was created in the C:\User\Sam\Documents\Visual Studio 2017\Projects directory with the specified name of AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler. This worked just fine, no errors. However due to a change in naming scheme from on high, the root directory for this project was changed from "C:\User\Sam\Documents\Visual Studio 2017\Projects" to "C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x". No problem, I thought - given that a co-worker who also happens to be a MS MVP had told me that all naming length restrictions had been removed in VS 2017. So...I moved the project from it's current home to the directory specified. Compiles just fine, brings in UPDATED BUT ALREADY INSTALLED nuget packages just fine, etc.
Or so I thought. When I needed to add a NEW (one that had not been a part of the solution before) nuget package to the mix, I received the above error. Turns out that the new name of the receiving solution is a few characters longer than VS will accept - the naming length restrictions are STILL IN PLACE.
How did I finally solve the problem: After struggling with this, I threw my hands up and decided to start all over again - a true File | New. So, I started with a new solution named as follows: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity" THIS GENERATES AN ERROR - name too long. I wondered at Nuget's error in that it specifies that the name should be less than 248 characters in length or 260 maximum.
What I am allowed to use iaw the new solution dialog is this: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", for a total of 106 characters in length. If the directory is shortened, I can add to the length of the name. If I shorten the length of the actual solution name, again, VS'll accept it. So long as the total length of directory plus solution name is less than or equal to 106 characters, there isn't a problem.
The nasty bit comes from creating the solution in one location and having it work in all respects just fine, moving said solution to a different directory, still having it function in all respects (I did NOT need to add any new nuget packages yet), then trying to add a new nuget package to the mix after the move. THAT is what triggered the above nuget error.
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
QUESTION
We have a .NetStandard2.0 project which is meant to be packaged into a nuget following the technique explained here:
...ANSWER
Answered 2019-Sep-13 at 01:33I've just found your issue could be related to the version of Nuget.Server package since you don't use nuget pack command. With same nuget package, when I use Nuget.server 2.10.3, it displays unsupported, After I update the Nuget.server to 3.4.1, all works well now. Let me know if it helps:)
I made a package locally, when I try to consume it in VS all works well. After I deploy same package to nuget server 2.10.3, it displays unsupported!
So if the issue occurs when you try to fetch the package from the server after you deploy to it. I think it's because the Nuget.Server package you use is too old! Updating the Nuget.Server package can help resolve this issue.
QUESTION
I have an XML like this:
...ANSWER
Answered 2019-Jul-02 at 08:21The Version element is in a different namespace that you did not declare in your PS script:
QUESTION
I have migrated nuget repository from Win 2008 to Win 2016. Alias to that server: http://xyz.mycompany.com/NugetFeed
Apart of windows, IIS is different as well, on the new server it is IIS 10.
After migration, nuget works pretty well, except one function. I can browse packages via web (http://xyz.mycompany.com/NugetFeed) or via Visual Studio etc. Visual Studio can see packages created manually.
The only problem is with the nuget push.
>nuget push FEDivaNET.dll*.nupkg -Source http://xyz.mycompany.com/NugetFeed/ D568CD48-1609-40C9-9A5D-7ADC808129E5
Pushing FEDivaNET.dll.3.41.73.nupkg to 'http://xyz.mycompany.com/NugetFeed/'...
PUT http://xyz.mycompany.com/NugetFeed/
NotFound http://xyz.mycompany.com/NugetFeed/ 128ms
Response status code does not indicate success: 404 (Not Found).
System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at NuGet.Protocol.Core.Types.PackageUpdateResource.<>c.b__23_0(HttpResponseMessage response)
at NuGet.Protocol.HttpSource.d__181.MoveNext()
- It is not a problem with the URL. When you try to modify URL then you will get different error
- It is not a problem with permissions to D:\MyServer\NugetPackages on server, as I have set full permissions to that folder. I have also moved packages folder to different locations (ie. some other external network drive), but I am having same issue.
I tried compiling 2 different Nuget.Server versions: 2.14.0 and 3.1.2 ...Same exception.
Inside IIS, I am pretty sure I have set same settings as on the old server. Also I have INTEGRATED pipeline mode, so everything is good. I also tried setting authentication via technical users etc.
Not sure where is the issue, I think I checked every single setting. I tried with APIKEY, and without APIKEY. I modified every single setting in the Web.config, no luck…..
...ANSWER
Answered 2019-Jan-10 at 13:16The url on which push the nuget packet is something like
http://{server}/{feed}/api/v2/package
So in your command use:
QUESTION
Forgive what must be a very simple oversight on my part but I simply cannot get this to work as expected.
I am building a .NET Framework 4.6 Class Library that needs to be downloaded by other applications from a private nuget repository. Here is my process:
- I have a test project, ConsoleApp5. It has a simple main function in it.
- I download my NuGet package, MyPackage (right click on project and click Manage NuGet Packages, select appropriate repo and package, click install.)
- I run my test. In this case, I'm simply trying to instantiate a class, something not difficult. I'm getting an error about class accessibility.
- Back in MyPackage, I replace all instances of the word
protectedwithpublic. I add a new class as well by right-clicking on the project, selecting Add Item, targeting a class and giving it the nameTestClass. - I go to Project > MyPackage Properties... > Application (tab) > Assembly Information, and I manually update the version patch number by one. So now it is 1.0.5.
- I go to the project directory in the Developer Command Line and run the following command:
C:\Users\jptak\Downloads\nuget.exe pack -Version 1.0.5 - Then I run the following command to push the update (Success message:
Your package was pushed.):C:\Users\jptak\Downloads\nuget.exe push MyPackage.1.0.5.nupkg MySecretCodeGoesHere -src http://my.nuget.server.goes.here.com - I go back to ConsoleApp5, Manage NuGet Packages, see the update in the appropriate package, and click the update arrow. The download completes and the new version number is there.
- I go to use new classes or check that old errors are fixed and all of my tests fail.
TestClassis not there.
This leads me to believe that the code I am writing is not making it to the NuGet server. Does anyone know what I am missing from this process to make the most recent version of the code get updated on the server?
This process is foreign to me as I am not a .NET developer (I work with PHP mostly).
Here are some more pieces of information about my IDE settings:
- In Build > Configuration Manager... > Debug has been switched to Release
- I have tried building, rebuilding, and cleaning my project. I haven't seen that any of these processes has had any effect on the code being pushed at all.
Here is the code from my ConsoleApp5:
...ANSWER
Answered 2019-Jan-22 at 17:08Bit long for a comment, not exactly an answer but here we go:
So top debugging tips for NuGet packages are:
Download the package manually. A
.nupkgfile is just a zip file that can be opened with 7Zip or any other archive tool.Once inside you can inspect both the
.nuspecfile that has been used to pack the package, and inside thelibfolder are the dlls that have been supplied.A decompiler like DotPeek or ILSpy can be used on the dll to see exactly what is going on inside the dll.
Possible causes of your symptoms could include the NuGet server giving a false success, or your application failing to update the package and still refering to the old one.
QUESTION
I'm hosting a private Nuget server built with Nuget.Server package.
The machine is exposing port 8082. The nuget server is available via web browser on http://domain:8082/nuget, publishing works fine.
Now I'm trying to enable VS2017 to consume packages from this nuget server. After adding new package source "http://mydomain:8082/nuget", I'm able to browse my packages, but Install-Package fails. Obviously it ignores the port number when building the download link.
Here's the output:
...ANSWER
Answered 2018-Oct-02 at 11:26The problem was caused by the network infrastructure settings. Port 8082 was forwarded to port 80, and Nuget server was listening on port 80. Since the urls were rewritten, there were no way for Nuget server to know the correct port number, so it responded with download links without custom port number.
Once I've created a port forward without actually changing the port number, i.e. 8083 to 8083 and set Nuget server to listen on 8083, everything works fine.
QUESTION
I'm currently trying to build my own nuget repository (like nuget.org).
In order to do so, I had a look at Nuget.Server. But when running this solution it crashes at a few packages, that can be downloaded from nuget.org (e.g. opencart.entities 1.0.2).
It crashes in ServerPackageStore.cs, line 83:
...ANSWER
Answered 2018-Aug-29 at 09:27How can I build the Nuget2 repo or is there maybe another way to tackle my problem with the Nuget.Server?
You also need download the solution NuGet.Client and unzip it to the folder NuGet.Client of your current solution.
When you download the solution NuGet2, you will find the folder NuGet.Client is empty. That is the reason why you got that error:
"error MSB3552: Resource file "....\NuGet.Client\src\NuGet.Core\NuGet.Frameworks\Strings.resx" cannot be found."
To resolve this error, please download the NuGet.Client solution and unzip it, copy all contents in the folder NuGet.Client-49234c230df0fc01868d8b90e667af89be8cc4f6 to the NuGet.Client folder, then build the project.
Hope this helps.
QUESTION
So I have created a NuGet Server via an ASP.Net Web Application following this tutorial: http://nugetserver.net/ which is hosted in IIS. I have placed the files on my D: drive on my server along with my packages.
I get the following error when I navigate to the url:
In case the picture is not clear enough, please see below:
Could not load file or assembly 'NuGet.Server, Version=2.11.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Here is my project's web.config file along with my publishing profile:
My target .NET Framework version is 4.6 but the packages themselves are those of an earlier version of .NET. Could this be the problem? I took the project folder and put it on my physical path on my local machine and it works just fine when I run the project in debug mode. Please see screenshot below:
NOTE: I have to hide the package names due to organizational confidentiality policies.
I am pointing to these package files:
...ANSWER
Answered 2017-Jun-28 at 07:43I could not replicate your error, but here are some notes how nuget server problems can be solved:
The packagesPath key in web.config can be left blank, as you are already using the default folder \Packages.
When deploying to the server, you might find an error in the line of Access to the path server.cache.bin is denied. Just create a blank file with that name on your server.
QUESTION
My environment: Windows 10 Creator (1703 with current updates to this date)
- Visual Studio 2017, Enterprise, 15.3 with most of the goodies turned on.
Windows 2016, again with all current updates.
- iis 10 with WebDeploy installed (that's a whole other installation nightmare, suffice it to say that SO helped there and the answers are already out there so I won't go into it here). Turned on ASP.NET 4.6, otherwise mainly accepted the defaults.
My process:
As per the NuGet.Server documentation, create a new ASP.NET MVC project using the "Empty" template and download and install NuGet.Server as specified. I'm using .NET 4.7 as my framework.
Compile and configure as desired (at least ensure you have an api key in place).
- Deploy to iis using the "Publish" | Web Deploy option
Try to get in touch with the NuGet.Server on the website and fail miserably! My bindings are 192.168.1.25 (yes, the server has a fixed IP address), port 80. The name of the site is AWENuGet and the desired url is www.awenuget.com.
To be sure, all of this works just fine if you take the same project as described above, assign a local port number (creating the project will do that anyway) and then simply running the application in Visual Studio works just fine.
But, when I took that self-same project and simply deployed it to iis, miserable failure.
I tried to open the host file (Windows\System 32\drivers\etc) and added the following:
192.168.1.25 www.awenuget.com
to said file and it still failed.
...ANSWER
Answered 2018-May-03 at 17:08...and the answer, for me, was to take that same hosts file entry that I made on the server so that the server could see it and install it in my dev machine's hosts file and voila! NOW it works just fine.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install NuGet.Server
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
