Skip to content

Instantly share code, notes, and snippets.

View yishaigalatzer's full-sized avatar

Yishai Galatzer yishaigalatzer

  • Amazon
  • Seattle, WA
View GitHub Profile
Running Shenandoah GC with 768M heap size
JVM configuration:
-Xlog:gc:batch.shenandoah-gc.768M.log -XX:+AlwaysPreTouch -XX:+UseLargePages
-XX:-UseBiasedLocking -XX:+DisableExplicitGC -Xms768M -Xmx768M
-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:+ShenandoahPacing
-XX:ShenandoahPacingMaxDelay=1
Extremem configuration
RandomSeed,42
InitializationDelay,50000
@yishaigalatzer
yishaigalatzer / Secondaryglobalfolder
Created May 14, 2016 02:20
Speed up restore on kudu and vs
### Goal
We want both nuget the CLI and msbuild based projects to be able to share a common set of packages on a machine.
The current global packages folder is per user and has to be populated once per machine. In azure deployment scenarios that will happen potentially on every deployment. Furthermore this data is on a persistent shared drive that is networked accessed making it much slower than a local drive in the dev scenario.
We want to speed up the initial restore and bring it to be comparable to existing desktop .net deployments.
### How
The suggestion is to configure a machine level expanded packages folder.
---
layout: post
title: NuGet ContentFiles Demystified
author: Jeffrey T. Fritz
comments: true
---
In NuGet 3.3, the `contentFiles` feature was introduced to support project.json managed projects and packages that are indirectly referenced in a project. This was an important change because it brings the ability to deliver static files, .pp file transforms, and language specific code into a project. In this post, we'll explore how to make use of this feature and show some samples of how to make the most of it in your projects.
## Definition

Feb-1-2016

Current search status We have two search services running side by side, for v2 and v3 protocols and we are in the process of unifying them for operational simplicity mostly. During this process we have found some bugs in the search indexer, and by fixing them along with some minor changes to the boosting algorithm we believe we have overall better results and better testability.

The new search is now being tested here - http://nuget-prod-0-v2v3search.azurewebsites.net/query?q=jil and it will show jil as first.

Algorithm description In general we look in the id, description, title and tags and we boost somewhat by downloads (but only for top packages). So potentially packages that have the same term in both id, description, title and tag might get a better score than one that have it just in the id.

@yishaigalatzer
yishaigalatzer / gist:f94003b399d4fd28091c
Created October 26, 2015 20:57
AppVeyor-GettingOffNuGetCore
Hi Feodor,
Code change is still in progress, but you may want to look at this commit: https://github.com/NuGet/NuGetGallery/commit/7f06ba9171328af3acfb0790584af5c518d3afe2
It uses these NuGet packages:
* NuGet.Frameworks (has compaitibility info)
* NuGet.Packaging (has a package reader, which from the below e-mail seems to be what would be your starting point)
Here’s an example of opening a package for reading. I created an extension method to read the NuSpec stream, but that is a very simple one calling into “new NuspecReader(stream)”.
https://github.com/NuGet/NuGetGallery/commit/7f06ba9171328af3acfb0790584af5c518d3afe2#diff-645a21b27c26500fcb04ecf496609bb8R52
The reason the filters are still in attributes is for back compat, so code doesn't have to be rewritten from existing MVC 5 applications. The mechanism to have the filter in another class is there, by using a FilterProvider introspect the IFilter and pick whatever implementation it wants. Also note that IFilter can also be just metadata to other filters. Every filter can see the rest of the pipeline and use it for picking up metadata or making bypass decisions.
<h3>Intro</h3>
<p>In this blog, I intend to provide a simplified how-things-work and how-to-change-the-behavior. It is not intended as a deep dive into content negotiation.</p>
<p>Since Web API 1 controller code can return an object of an arbitrary type and the framework will send it as JSON or XML to the client. The process of picking the output format is called “content negotiation”. The basic rules can be described simply as:</p>
<p>1. The framework will attempt to return the format that the client asked for using the <strong>Accept </strong>header.</p>
<p>2. In absence of a specific format requested or inferred, the default format is JSON. </p>