joelverhagen

using NuGet.Client;
using NuGet.ContentModel;
using NuGet.Frameworks;
using NuGet.Packaging;
using NuGet.Packaging.Core;
using NuGet.RuntimeModel;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;

joelverhagen

// All you need is the NuGet.Protocol package from NuGet.org.
using System;
using System.Threading;
using System.Threading.Tasks;
using NuGet.Common;
using NuGet.Protocol;
using NuGet.Protocol.Core.Types;

namespace ConsoleApp1
{

joelverhagen

import os
import collections
import urllib

from pm4py.objects.log.log import EventLog, Trace, Event
from pm4py.objects.log.exporter.xes import exporter as xes_exporter

solutionNameToSourcesToEventLog = {}

for (dirPath, dirNames, fileNames) in os.walk(r"logs"):

joelverhagen

joelverhagen

    nuget.enableUsabilla = function (obfuscatedPath) {
        // If there is an obfuscated path, hook into the outgoing AJAX request containing the feedback and obfuscate
        // the URL data. This approach was provided by the Usabilla technical support.
        if (obfuscatedPath) {
            var obfuscatedUrl = document.createElement('a');
            obfuscatedUrl.href = window.location.href;
            if (obfuscatedPath.substring(0, 1) != "/") {
                obfuscatedUrl.pathname = "/" + obfuscatedPath;
            } else {

joelverhagen

There are many differences between the V2 and V3 APIs. For nuget.org, the main difference is how they are implemented. V2 API is built on top of SQL Server and the V3 API is built on top of Azure blob storage and Lucene for search.

As nuget.org's traffic increased exponentially, it became harder and harder to mean the traffic demands with a SQL database. As you may know, Azure SQL gets very expensive as it scales up and has a maximum size it can reach. Therefore, V3 was implemented on technologies that a small team could easily manage as traffic increased. All of the V3 endpoints used for `nuget.exe restore` are implemented on top of blob storage, which has great availability, is quite cheap, and can be further improved with a CDN in front. I am glossing over details a bit but that's the key difference when V3 split off in the way it did.

V2 is a much more flexible API since it is built on top of OData and therefore supports arbitrary queries beyond the ones nuget.exe performs. For example, you can sort by 

joelverhagen

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp2.2;net462</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'net462'">
    <Reference Include="System.Net.Http" />
  </ItemGroup>

joelverhagen

using System;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Starting");

joelverhagen

using System;
using System.ComponentModel.DataAnnotations;
using System.Diagnostics;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Logging;

namespace ConsoleApp1
{

joelverhagen

NuGet Package Version Conventions

CI packages and release packages

A common pattern for NuGet package versions is producing two sets of .nupkgs for every CI build. That is two sets of functionally equivalent packages produced from the same source. Two sets are:

1. CI packages: a NuGet package version that is suffixed with a build number. This allows bleeding edge consumption of the latest APIs or fixes. These packages are typically pushed to a development package feed like VSTS or MyGet. Example version numbers: 4.0.0-rc-2046, 3.5.0-rtm-1996, 3.5.0-beta2-1543