Hello and welcome to MyGet Blog!

What We Discovered from a Product Survey

We recently invited the MyGet community to take part in our first annual product survey! We wanted to learn more about you, our customers, and how you've been storing, managing, and distributing your packages with MyGet.

We learned a lot about what you like best about MyGet and what we need to improve thanks to your open participation. We are excited to share the results with you as well, as they will help us all better understand the community that is MyGet! Here are our key takeaways from the findings.

Designed by developers for developers

First and foremost, we learned more about you! As we consider how to expand the functionality of MyGet, it's critical that we understand who uses our platform and what challenges you face. (In an increasingly remote world, it's critical to stay connected as a community!)

More than 85 percent of the more than 750 people who took part self-identified as having a technical role on your team, whether as a developer/software engineer (58 percent), architect (12 percent), DevOps/IT engineer (12 percent), or Tester/QA team member (3 percent ) .

NET, JavaScript, and HTML are the top three.

MyGet was affectionately referred to in its early days as "NuGet-as-a-service." That was the need it was designed to fill—a simple way for you to reap the benefits of a private NuGet server without the hassle of managing installation or infrastructure. As a result, it's not surprising that Microsoft.NET languages are the most popular among MyGet community members.

What is intriguing is the proportion of Python users who have joined MyGet in the last year. Outside of.NET, JavaScript, and plain HTML/CSS, Python developers account for the majority of the MyGet community, outnumbering Java developers by 2%. We're not just a NuGet family anymore; the MyGet tent has expanded, and some of you have spread your programming wings.

On the one hand, given Python's growing popularity, we might expect to see a fair number of responses from Python developers in our survey results. (According to the RedMonk Programming Language Rankings, Python has risen to second place among the most widely used programming languages.)

On the other hand, one of the most recent features we've added to MyGet is Python PyPI support. It's encouraging to see how many MyGet community members benefited from the addition of Python packages alongside NuGet, npm, Bower, Maven, and Composer packages. Python PyPI packages climbed to the number 5 spot in our list of most-used package formats in less than six months, surpassing other package manager types that we've supported for much longer and challenging Maven for the number 4 spot.

What role does MyGet play in your DevOps lifecycle?

Over 98 percent of you said you use source control for the proprietary code you write, which is a good thing because source control is a must-have for modern software development. Almost all of you who use source control use Git, and your top five hosting platforms are Github, Azure DevOps (split between cloud and server), Bitbucket, GitLab, and Assembla.

Integrating MyGet with your CI/CD processes is one of the most effective ways to leverage the artefacts you store in MyGet. More than 85% of you said you've already embraced continuous delivery and integration, using a variety of tools like Azure DevOps, Jenkins, TeamCity, GitLab, Bamboo, Appveyor, and Travis CI to run builds and push build artefacts to MyGet.

What motivates you to use MyGet?

MyGet's nature as a hub between multiple spokes of the SDLC allows for a wide range of different use cases. Having said that, more than 68 percent of you reported using MyGet to share private packages within your internal team. The following three most-reported use cases received roughly the same number of responses: 23 percent of you use MyGet to store build artefacts, 21 percent use MyGet to control the open source packages used in your development environment, and 20 percent use MyGet to host open-source packages you've built and shared with the community/public.

What did you request that we prioritise next?

MyGet's success is dependent on our ability to constantly improve features that make your lives easier and assist you in shipping better products. Despite the rise and adoption of third-party CI/CD platforms in the MyGet Community, more than 75% of you stated that

It was still important to you to update MyGet's build services to support.NET Core 3 and C# 8. Improving uptime and availability, your second-most requested improvement, has been high on our priority list for quite some time, so we are pleased to see that this aligns with your concerns. Your feedback has been extremely beneficial as we've worked to finalise our roadmap for the upcoming fiscal year. Thank you again for your candid feedback—we will be able to be much more focused on delivering the improvements that are important to you as a result of it!

We're almost done!

We're delighted to have had the opportunity to share these insights with you. The more we connect and learn about your preferences for using MyGet, the better we can help you manage your packages and ship better products.\

Please contact me! We enjoy hearing your stories and ideas. Contact us at [email protected], start a chat with us at https://myget.org, or follow us on Twitter or Facebook. And be sure to visit our UserVoice page on a regular basis to vote on our roadmap and stay up to date on our most recent releases (such as our NuGet Symbol Server update, which was your top-voted request on UserVoice)!

NuGet is now supported by MyGet. Symbols for snupkgs!

Improved debugging and source code support in MyGet NuGet feeds

MyGet was created to remove the tedious aspects of packaging so that you can focus on solving more interesting problems and creating awesome things.

In 2016, we added support for an integrated NuGet Symbol Server to make it easier to debug NuGet packages hosted on MyGet. When MyGet first added NuGet Symbol support, you could push your NuGet packages to the same package feed as their debugging symbols. You could also use MyGet feeds to search for libraries and symbols, and access both from Visual Studio. In late 2018, NuGet.org launched their integrated symbol server hosting.

We are pleased to announce that MyGet now supports both NuGet.org's new.snupkg symbol package format and the original.symbols.nupkg format, as of today. You can push both.snupkg and.symbols.nupkg symbols based on your needs, and use the same streamlined workflows for both as before.

On MyGet, how do I use NuGet symbol packages?

Your NuGet packages and symbols are stored in the same feed on MyGet, making it easier to access them for debugging.

The endpoint for pushing.snupkg symbols packages is the same as for regular NuGet packages.

"https://www.myget.org/F/somefeed/api/v3/"

If both the.nupkg and.snupkg files are in the same folder on your machine, you only need to enter the push command once to push your.nupkg and.snupkg assemblies to MyGet—MyGet will automatically detect and upload if there is a.snupkg file!

You can also use MyGet.org to upload symbol files directly to MyGet.

After you've uploaded your symbol package to MyGet, you'll be able to download it from MyGet.org, retrieve it from a MyGet API endpoint, or access it directly from Visual Studio.

What about the symbols I already have on MyGet? Will MyGet keep supporting the.symbols.nupkg format?

We will continue to support both the.snupkgs and.symbols.nupkg formats. However, if you have an existing NuGet symbol in the legacy symbols format on MyGet and want to update it to the new.snupkg format, the old version will no longer be available from the "Download symbols" link in your feed gallery at MyGet.org after you update. (However, MyGet will not completely remove the legacy package, and you will still be able to search for and download the legacy in Visual Studio if necessary.)

When I use MyGet Build Services, where do my symbol packages go?

Symbol packages are automatically pushed to your MyGet feed when new feeds are added. You can choose where to push symbol packages from the build configuration.

Where can I find MyGet documentation for.snupkgs?

To learn more about creating, publishing, and downloading symbols, visit the MyGet Docs page on Symbols.

snupkgs can be obtained from MyGet.org or the MyGet API.

We want to hear from you!

Do you want to see other enhancements or new features in MyGet? Use our Uservoice feature request board to submit your idea or vote on one of the community's existing ideas. Please let us know if there is anything else we can do to assist you! Start a chat with us on myget.org or send us an email at [email protected], and we'll get back to you as soon as possible.