MyGet is used within Dangl IT GmbH as a central source for all our deployed packages, thus allowing us to structure our software projects logically and reuse existing code where applicable.

So far, we haven't had any problems with MyGet, it works as expected. We would like to see the addition of upstream sources, since we've never been able to get this working, but this is a low priority for us at the moment.

Overall, I've solved some serious problems that stem from trying to get everybody to have the same version of packages - developers, QA, and clients get the right stuff, and that makes a lot of work just plain go away. The setup was not horrible and consultants are productive. I can't think of a better experience!

MyGet has revolutionized how I've done consulting. I used to use Git subrepos to bring code into projects, since I didn't want to put NuGet packages in a public place. Now that I have pioneered using MyGet, a company with whom I work is pulling together all of our Maven, NuGet, and npm packages. The administration and delivery for MyGet is awesome, and uploading packages is mostly pretty easy. For the money, this is a no-brainer for the organization: we can deliver packages to clients without everybody having access to source code. I love it.

It took me some time to figure out how to get the permissions set up. There is a way to get a pre-authorized URL, which I would prefer not to do. However, I've seen NuGet have some trouble authenticating from QA machines. I don't have an answer for that, but I feel authorization could be a little more clear. I would love to see a Docker registry! I went with MyGet over GitHub's package manager because we don't use GitHub for anything else, but it was a close call. I hear that MyGet is working on Docker registries. At that point, I believe MyGet will satisfy more than my needs...like all of my wants, too.

MyGet is one of the good 3 options for a package registry as a service in my humble opinion. That being said, I'd love to see more new features (or more communication) and better up-time.

MyGet has a very good interface for looking at your feeds. The API works. They just (March of this year 2020) added snupkgs support which is nice, but they're are a few competitors which have had this for a while. While this is true with most private package registries, the registration and authentication for your registry is very simple.

The biggest difficulty for us with MyGet is their up-time. We depend on MyGet for a majority of our builds so when MyGet is down, most of our builds are down. This hit us ESPECIALLY hard during a release where we had the majority of a day (in November 2019) where we couldn't build. We actually moved some of our packages to GitHub Packages for the day so we could continue for a bit. As of 2018, new features (or at least posts about new features) have died down a bit. They appear to be either slowing down in new development or just simple not communicating as much.

It has been easy to setup, consume, and maintain.

We needed as easy to setup and consume private nuget feed. We found that in MyGet.

Honestly, since all we were looking for was a private nuget feed that we didn't have to host, MyGet had everything that we wanted. I haven't encountered a gap in features.

Solid performant service.

MyGet lets us build and store our private npm packages, as well as keep a copy of every dependency we use so we are protected from another leftpad incident. We are also able to protect ourselves from an old dependency being taken over by a malicious maintainer.

It's hard to update dependencies of dependencies of dependencies. (3 levels deep). 2nd level dependencies are easily updated.

It is simple to use, supports a large number of programming languages, and comes with built-in instructions that developers may utilise to enhance user experience. Its user-friendly interface enables me to do my file management and organising activities more quickly and easily; also, the fact that I can control everything from the cloud greatly reduces the risk of overtaxing my computer.

All of the functions that MyGet offers are not being fully utilised. We continue to use the services provided by our SaaS SourceCode supplier for internal development feeds. The majority of our new developers were unfamiliar with the user interface because it is a little dated.

Easy to use and followed by developers. User and access maintenance nightmare.

In our company we have a few technology stacks, MyGet has become a single repository of our dependencies that can accommodate various type of feeds (NPM, NuGet and Bower)

Separate user management and MyGet is managing separate identity (although SSO is setup) which cause ex-employees remain have access to the feeds.

MyGet enables us to quickly deliver shared code base (100+ packages) to all of our teams. The setup is really easy, adding a new user consists of sending an email invite, generating the pre authenticated url and voilà (no msdn subscription or such needed)

Nothing, we absolutely like everything about this product.

I use MyGet on my personal projects. It is is integrated with my CI where the generated Nuget packages (.net) are published to it. Once I'm satisfied with the Nuget package being stable, I manually push upstream from MyGet to Nuget

Setting up an account and getting up and running with MyGet is fairly easy. It's clear to see that it's a tool that makes your life easier when publishing your packages.

When I first started using it the navigation between your projects/packages and its versions didn't feel natural to me. But it was just a 5 minutes thing to learn how things are structured in the app, and then you overcome the issue.

easy to use for me as a user

MyGet manages software packages, it works well as SaaS for us.

as MyGet goes offline sometimes, I'd like to see on-prem active backup option.

My team has been using MyGet for several years now. Before using MyGet we had a hodgepodge of homegrown private package repositories and it was a burden on our team to maintain them. Integrating MyGet into our toolstack and build servers was seamless and painless. Our team recouped valueable time after migrating to MyGet and was able to use that saved time towards actually writing our software. I'd say the best feature of MyGet is the wide support for different package sources.

I wish there was a way to do Single Sign On through either SAML2P, Shibboleth or CAS. That's probably the only feature lacking right now that we really want. MyGet recently, in the grander scheme of things, implemented 2FA and that was a really big win for us.

We use it to distribute our software. New builds are posted on myget and installed with chocolatey. It was great, until the day it wasn't and then it was terrible. The complete and utter lack of ownership of the problem was the most frustrating part. I would not recommend myget to anyone based on this. We will move off of it without hesitation once we have an alternative.

Easy to set up, easy to use, and generally low cost. We got our feed set up and didn't touch it for a long time.

At some point late 2020 our artifact size went over 100MG per build. We started getting rejections when trying to post it. The error message was clear, we needed to pay for more capacity. Ok, no problem. So we paid for more capacity...and the error didn't go away. We gave it a few days, still didn't correct itself. Contacted support. They made a ticket but there was no progress. This goes on for months. We are manually uploading builds this whole time (while paying the increased rate!). Support keeps saying they can't help personally, they don't know when someone who can will look at it, and that's it. It totally sucked.

It has been a successful NuGet repository service for a long time, is reliable, and above all, very easy to use in terms of administration. I have 100% recomendation for using it, at least for OSS. Compared to the competition, it is neutral and easy to handle, with almost no constraints in terms of DevOps, and there is little reason to choose any other service. Pricing, however, is difficult to choose a level. In my case, I use OSS almost exclusively, but I'm willing to pay for it and charge for it. But the entry level `Developer` is expensive. For paid work, if a competitor is available for free, MyGet is rejected when I propose it.

* Very easy to use management console. * Can deploy and publish a NuGet package in 5 minutes. * Very simple and clear configuration. * No extra restrictions.

* The hierarchical structure of the repository is confusing. If the menu structure is organized, the problem will disappear. * The pricing structure needs to be a bit more segmented, with a level where entry-level users do not hesitate to pay. free use is available for OSS use, which is great, but capacity restrictions are tight. Even if they want to pay to avoid this restriction, the current `Developer` seems expensive for OSS and hobby use.

It was very easy to sign up and setup. We combine github, teamcity, MyGet, and Octopus Deploy to give us an automated build and deploy process. We also use MyGet as a source for our own custom written chocolatey packages. MyGet also allows for easy management for example, configuring retention rules, marking favourite package versions, or upgrading the subscription levels.

It would be good to have an api to mark favourite builds to keep without having to log into the portal. For example so when we deploy a production release we can have an octopus deploy step which marks the packages used in that deployment as a favourite build so they arent cleared away automatically by the retention rules.

Overall I really like using MyGet in my organization managing our packages and feed details. Easy touse after you get a hang of it.

MyGet is great to work with Software dependencies and package management between different members in a development team. It is very easy to create/share private NuGet feeds. I also like the feature that you are able to create private repositories and it's Integration with Visual Studio Team services while working in a .net environment, thereby lessening load for DevOps working your organization. It is easy, fast and secure to use.

The User Interface is not very informative about the features it has to offer. It can sometimes be an overhead to manage your packages in a different platform but it is definitely worth the effort.

It is in the backlog to seek a replacement and it is guaranteed to happen. It isn’t an attractive offer anymore given what I mentioned above. The only thing that’s stopping us is that many moving parts depend on that NuGet feed, so it’s not a quick lift and shift.

It’s a NuGet feed I don’t need to set up and maintain.

I only need NuGet feed functionality. Updated plans include a lot of other stuff I will never use, but will be paying for and they don’t include nearly as much storage capacity for the same money. Attempts to update the plan failed... it just wasn’t working at all. Over the last few months there have been several major outages that paralysed our workflow for considerable time. The service seems to be poorly designed in terms of availability judging by explanations of the issues in Twitter.

The service itself seems to be very reliable.

The customer service is almost non-existent. We had a week and a half outage trying to get issues fixed with billing after the [SENSITIVE CONTENT] of our license left the company. There's no contact number for support or billing, and we were only receiving one email per day while trying sort out the issue. This should have been a pair of 15 minute phone calls. In the end, we restored functionality by taking over the absent admin's work email and resetting his password then transferring the nuget feed back to the defunct admin's account. MyGet billing and support was less than useless in fixing this problem since their poor response times helped drag this out.

i ve used for a while, as a user i can only complain about the thing i've described in the previous section

I've used myget in 2 different organizations and both of them got away from it. I think that the main reason is that myget is just about package managment . But there are other tools who do a lot more. So they prefer to use a single tools to save money and avoid using multiple tools within the same organization

that it lets you overwrite an existing version of a package. it was always a problem that we had to solve on our side. you should have some kind of option that would deny an existing package to be overwritten later on with a package with the same name and version

Yes, I loved this product. it really helped me a lot in managing my required packages during coding. It is very reliable in order to trust it. I am having a great time using it, it helps you and you don't need to go again and again over the internet to find out the packages, it provides all of them in a single packet.

It contains all the packages and provides you a very easy approach to use them. you can use any language to write your code and need any kind of packages in your program, you can simply go for MyGet.

Yes, you can't expect everything in a single product or tool. So here also we have some of the things which need to be overcome like:- customization of MyGet with other tolls or products, it is really very hard to customize it and also it would be great if it can come up with some scripts.

By providing free hosting for open-source projects, MyGet really helped to bring our free software project off the ground in terms of distribution.

The ability to host a curated feed to our users. This was essential as it gave them a much needed shield from all the noise in communal package managers.

Literally nothing relative to the core of the product itself. Some basic features such as changing the logo of the feed feel like they should be easy to change. However reaching out through support was not a great way to put you directly in touch with the development team.

I really appreciate a centralised registry allowing us to host packages for several languages such as node.js (NPM) and .NET (NuGet). Authentication and publication is pretty straightforward, once tooling is in place with for instance semantic-release, it is as easy as merging PR to master to get a new version up and running.

The administration of feeds could be a bit simplified. We have a feed that is owned by one of our administrator, but the subscription is linked to our client. The issue is that forwarding ownership // subscription, if I understand it correctly require to reset the payment method, which is something tricky in our case... I would like more flexibility in the subscriptions, to be able to forward ownership without risking to lose the plan even temporarily.

We're using MyGet to host NuGet private feed with our libraries. So far the overall experience is really great.

• the approach with the pre-authenticated feeds is great since it simplifies the access in CI/CD scenarios • legacy subscriptions are still active, thank you!

• a little bit immature UI, but this is a pretty minor thing

I will think later on if our issue gets resolved.

Customer support is pathetic. We got impacted on prod environment but no solution for weeks.At least team should let us know if we are doing something wrong while pushing packages.

If you have a large/medium prj with reusable components/libraries and a distributed team, MyGet is the place where shares anything needed easily.

Perhaps a more flexible cost plan, like a "per user"... even if I can understand that it is not so easy to take it under control.

It was very easy to set up and start using MyGet feeds. The hardest part was getting my company to find an approved vendor to buy it through.

I don't think about MyGet very much. There's a good reason for that. I set it up, and it just works.

So far, there's nothing not to like and we use it every day.