At the end of last sprint we flipped the switch on a new feature for Azure Artifacts called Universal Packages. With Universal Packages teams can store artifacts that don’t neatly fit into the other kinds of package types that we support. A Universal Package is just a collection of files that you’ve uploaded to our service and labelled with a name and version.
On the 24th of July 2018, we notified some customers via e-mail and on this blog about a planned action that we would start taking in relation to the malicious ESLint NPM package incident. This action is now underway.
Until now, we’ve focused on making Package Management in Visual Studio Team Services and Team Foundation Server the best place to store your private NuGet and npm packages, but we haven’t focused as much on the packages you use from public sources like NuGet.org.
As far back as 2012, Visual Studio Team Services and Team Foundation Server users have been asking for a Symbol Server. Symbols are crucial to debugging Windows applications, esp. applications written in native languages like C and C++, because they map from the built binary back to the source code: the classes and functions needed to step through an application line-by-line.
NuGet (both the command-line tool and the accompanying tools built into Visual Studio) continues to iterate rapidly and add support for new .NET Core and .NET Standard target frameworks, among other improvements. Naturally, many users of Team Build in Visual Studio Team Services want to build those apps,
To demonstrate our continued commitment to support Java developers and their full lifecycle DevOps needs with Visual Studio Team Services (VSTS) and Team Foundation Server (TFS), I want to share some of our recent and exciting Java-related feature announcements. Our teams are working with large and small Java teams every day to better understand their needs and to solicit recommendations for improvements of our tools.
Each month, we bring you the insiders view into Visual Studio Team Services – how the product is developed, how we dogfood it and use it every day, who are the people behind it and tips and tricks on becoming a power user
This is the third and final post in a series covering strategies for versioning a NuGet package. If you missed part 1 or part 2, you should read those first. Today’s post walks through a specific workflow that Git users could adopt,
This is part 2 in a series of blog posts covering strategies for versioning a NuGet package. If you missed part 1, pick it up here. Today’s post talks about future improvements we’d like to make to the versioning and releasing flows.
On the Package Management team, we’re frequently asked how to think about versioning packages. Conceptually, it’s simple: NuGet (like many package managers) prefers semantic versioning (SemVer), which describes a release in terms of its backwards-compatibility with the last release. But for teams that have adopted continuous delivery,