I've been reviewing the code for NuGet3 on GitHub, and I see several folder patterns in https://github.com/NuGet/NuGet3/blob/a5bc907d36ddaa8d4fa6c499e50d7ebf8993ed39/src/NuGet.Client/ManagedCodeConventions.cs related to expected folder structures within a NuGet package. However, I'm having a hard time finding any examples of these - specifically the rid and tfm values.
How can I know all the possible values for rid and tfm? I know they mean Runtime Identifier and Target Framework Moniker, but I don't really know what to do with that.
The documentation that I've seen never seems to deal with the topic directly or exhaustively.
The target frameworks are currently hard coded within the NuGet source code. Whilst some of the target frameworks are documented on the NuGet website there are many which are not documented there. So as Jeff R already mentioned the best way to find the target frameworks is currently to look at the NuGet source code.
NuGet version 2 target frameworks.
NuGet version 3 target frameworks
NuGet also has short identifiers for some of these frameworks (e.g. wp = WindowsPhone).
The runtime identifiers defined by Microsoft are available in the Microsoft.NETCore.Platforms NuGet package. Inside this NuGet package is a runtime.json file with the runtime identifiers:
{
"runtimes": {
"base": {
},
"any": {
"#import": [ "base" ]
},
"win": {
"#import": [ "any" ]
},
"win-x86": {
"#import": [ "win" ]
},
"win-x64": {
"#import": [ "win" ]
},
"win7": {
"#import": [ "win" ]
},
"win7-x86": {
"#import": [ "win7", "win-x86" ]
},
"win7-x64": {
"#import": [ "win7", "win-x64" ]
},
"win8": {
"#import": [ "win7" ]
},
"win8-x86": {
"#import": [ "win8", "win7-x86" ]
},
"win8-x64": {
"#import": [ "win8", "win7-x64" ]
},
"win8-arm": {
"#import": [ "win8" ]
},
"win81": {
"#import": [ "win8" ]
},
"win81-x86": {
"#import": [ "win81", "win8-x86" ]
},
"win81-x64": {
"#import": [ "win81", "win8-x64" ]
},
"win81-arm": {
"#import": [ "win81", "win8-arm" ]
},
"win10": {
"#import": [ "win81" ]
},
"win10-x86": {
"#import": [ "win10", "win81-x86" ]
},
"win10-x64": {
"#import": [ "win10", "win81-x64" ]
},
"win10-arm": {
"#import": [ "win10", "win81-arm" ]
},
"aot": {
"#import": [ "any" ]
},
"win-aot": {
"#import": [ "win", "aot" ]
},
"win-x86-aot": {
"#import": [ "win-aot", "win-x86" ]
},
"win-x64-aot": {
"#import": [ "win-aot", "win-x64" ]
},
"win7-aot": {
"#import": [ "win-aot", "win7" ]
},
"win7-x86-aot": {
"#import": [ "win7-aot", "win7-x86" ]
},
"win7-x64-aot": {
"#import": [ "win7-aot", "win7-x64" ]
},
"win8-aot": {
"#import": [ "win8", "win7-aot" ]
},
"win8-x86-aot": {
"#import": [ "win8-aot", "win8-x86", "win7-x86-aot" ]
},
"win8-x64-aot": {
"#import": [ "win8-aot", "win8-x64", "win7-x64-aot" ]
},
"win8-arm-aot": {
"#import": [ "win8-aot", "win8-arm" ]
},
"win81-aot": {
"#import": [ "win81", "win8-aot" ]
},
"win81-x86-aot": {
"#import": [ "win81-aot", "win81-x86", "win8-x86-aot" ]
},
"win81-x64-aot": {
"#import": [ "win81-aot", "win81-x64", "win8-x64-aot" ]
},
"win81-arm-aot": {
"#import": [ "win81-aot", "win81-arm", "win8-arm-aot" ]
},
"win10-aot": {
"#import": [ "win10", "win81-aot" ]
},
"win10-x86-aot": {
"#import": [ "win10-aot", "win10-x86", "win81-x86-aot" ]
},
"win10-x64-aot": {
"#import": [ "win10-aot", "win10-x64", "win81-x64-aot" ]
},
"win10-arm-aot": {
"#import": [ "win10-aot", "win10-arm", "win81-arm-aot" ]
}
}
}
I took some time to review the docs and look at the code. Most of this answer comes from the code.
TargetFrameworkMoniker / tfm is constructed by using one of the constants from FrameworkIdentifiers in FrameworkConstants.cs . It is a framework identifier, plus a version concatenated on the end. Some examples include:
net451 (.NET 4.5.1)
dotnet (sort of a "current" tag for the latest .NET / portable class library)
uap10.0 (Universal Windows Application, for version 10, the latest as of this post)
native (for C/C++ code packaged using NuGet. Also take a look at CoApp if you intend to use this one)
MonoTouch
MonoAndroid
Xamarin.iOS
Plus others you can find in the code linked above.
For runtime identifiers, they are composed of an operating system identifier of some sort, plus an architecture. So, in JsonRuntimeFormatTests.cs you can find a few examples.
These include:
win8-x86
win10-x64
win10-arm
etc
This information has helped me structure a NuGet package that uses the runtimes folder, as I was struggling to know what the possible values were. I hope it helps someone else.
Related
VS Code has support for schemastore which gives you autocomplete in YAML files.
But VS Code does not detect the schema if the filename is different.
For example, if I edit .golangci.yaml the corresponding schema gets used. If I edit .golangci-foo.yaml the schema is not detected.
How can I enable the schema for files where the filename is different?
You can do this using the json.schemas setting. Like so:
"json.schemas": [
{
"fileMatch": [ "*tsconfig*.json" ],
"url": "http://json.schemastore.org/tsconfig",
},{
"fileMatch": [ "*cSpell.json" ],
"url": "https://raw.githubusercontent.com/streetsidesoftware/cspell/cspell4/cspell.schema.json",
},{
"fileMatch": [ "*.webmanifest" ],
"url": "http://json.schemastore.org/web-manifest",
},{
"fileMatch": [ "*package*.json" ],
"url": "https://json.schemastore.org/package",
}
],
As indicated in the comments, this worked for the asker, and they used the following:
"json.schemas": [
{
"fileMatch": [ "*.golangci*yaml" ],
"url": "https://json.schemastore.org/golangci-lint.json",
}
],
How to parse the below log line using grok
Also how to match the pattern of the date.
I tried %{TIMESTAMP_ISO8601:logtime} but no match
Log Line:
13-Nov-2019 00:00:20.230 DEBUG [[ACTIVE] ExecuteThread: '272' for queue: 'weblogic.kernel.Default (self-tuning)'] [196.157.7.12] 965929132 [wire] >> "[\n]"
The question is a bit unclear as to exactly what fields you want them mapped to.
So, here's what matches for me:
%{MONTHDAY:day}[-]%{MONTH:month}[-]%{YEAR:year} %{TIME:time} %{WORD:logtype} \[\[%{WORD:status}\] ExecuteThread: '%{NUMBER:threadNumber}' for queue: '%{GREEDYDATA:queueData}'\] \[%{IP:ip}\] %{NUMBER:numbers} \[%{WORD:text}\] >> "\[\\n\]"
The first 4 fields, answer your date/time pattern query and the rest is what I have used to fit the rest of the fields. Since, no exact mappings were provided , I have mapped them as per my understanding using
This is the output:
{
"day": [
[
"13"
]
],
"month": [
[
"Nov"
]
],
"year": [
[
"2019"
]
],
"time": [
[
"00:00:20.230"
]
],
"logtype": [
[
"DEBUG"
]
],
"status": [
[
"ACTIVE"
]
],
"threadNumber": [
[
"272"
]
],
"queueData": [
[
"weblogic.kernel.Default (self-tuning)"
]
],
"ip": [
[
"196.157.7.12"
]
],
"numbers": [
[
"965929132"
]
],
"text": [
[
"wire"
]
]
}
You can break 'time' further if you want. For any other combinations of patterns, refer Grok Patterns.
I came across this page discussing different hash functions that mcrouter can use, but could not find an example of how a hash function can be configured if you do not want to use the default ch3. In my case, i would like to use the "wch3" with a balanced (50/50) weight between two nodes in a pool. How can i manually change the default to configure wch3?
Thanks in advance.
Here is an example that can help you:
{
"pools": {
"cold": {
"servers": [
"memc_1:11211",
"memc_2:11211"
]
},
"warm": {
"servers": [
"memc_11:11211",
"memc_12:11211"
]
}
},
"route": {
"type": "OperationSelectorRoute",
"operation_policies": {
"get": {
"type": "WarmUpRoute",
"cold": "PoolRoute|cold",
"warm": "PoolRoute|warm",
"exptime": 20
}
},
"default_policy": {
"type": "AllSyncRoute",
"children": [{
"type": "PoolRoute",
"pool": "cold",
"hash": {
"hash_func": "WeightedCh3",
"weights": [
1,
1
]
}
},
{
"type": "PoolRoute",
"pool": "warm",
"hash": {
"hash_func": "WeightedCh3",
"weights": [
1,
1
]
}
}
]
}
}
}
You can adjust the weight in the range [0.0, 1.0].
I am new to MongoDB and I am stuck trying to get unique subdocuments in an array.
A document in my collection looks like this:
{
"PubDate": "1/01/01 00:00",
"Title": "Identification of DNA-Dependent Protein Kinase Catalytic Subunit (DNA-PKcs) as a Novel Target of Bisphenol A",
"Datums": [
{
"evidence_id": "3515620_6",
"evidence": [
"\n\nTo examine the interaction between DNA-PKcs and Ku70/Ku80 more directly, we performed immunoprecipitation (IP) using FLAG-Ku70 or FLAG-Ku80 recombinants, which were expressed in 293T cells after IR-irradiation (Fig. 4B\n ) or UV-irradiation (Fig. 4C\n ). After IR-irradiation, co-precipitation of DNA-PKcs with Ku80 increased compared with that in the non-irradiated controls (Fig. 4B\n lanes 7 and 8)."
],
"map": {
"change": [
{
"Text": "increased"
}
],
"subject": [
{
"Entity": {
"strings": [
"dna-pkcs"
],
"uniprotSym": "P78527"
}
}
],
"treatment": [
{
"Entity": {
"strings": [
"dna-pkcs"
],
"uniprotSym": "P78527"
}
}
],
"assay": [
{
"Text": "copptby"
}
]
}
},
{
"evidence_id": "3515620_6",
"evidence": [
"\n\nTo examine the interaction between DNA-PKcs and Ku70/Ku80 more directly, we performed immunoprecipitation (IP) using FLAG-Ku70 or FLAG-Ku80 recombinants, which were expressed in 293T cells after IR-irradiation (Fig. 4B\n ) or UV-irradiation (Fig. 4C\n ). After IR-irradiation, co-precipitation of DNA-PKcs with Ku80 increased compared with that in the non-irradiated controls (Fig. 4B\n lanes 7 and 8)."
],
"map": {
"change": [
{
"Text": "increased"
}
],
"subject": [
{
"Entity": {
"strings": [
"dna-pkcs"
],
"uniprotSym": "P78527"
}
}
],
"treatment": [
{
"Entity": {
"strings": [
"dna-pkcs"
],
"uniprotSym": "P78527"
}
}
],
"assay": [
{
"Text": "copptby"
}
]
}
},
{
"evidence_id": "3515620_6",
"evidence": [
"\n\nTo examine the interaction between DNA-PKcs and Ku70/Ku80 more directly, we performed immunoprecipitation (IP) using FLAG-Ku70 or FLAG-Ku80 recombinants, which were expressed in 293T cells after IR-irradiation (Fig. 4B\n ) or UV-irradiation (Fig. 4C\n ). After IR-irradiation, co-precipitation of DNA-PKcs with Ku80 increased compared with that in the non-irradiated controls (Fig. 4B\n lanes 7 and 8)."
],
"map": {
"change": [
{
"Text": "increased"
}
],
"subject": [
{
"Entity": {
"strings": [
"dna-pkcs"
],
"uniprotSym": "P78527"
}
}
],
"treatment": [
{
"Entity": {
"strings": [
"dna-pkcs"
],
"uniprotSym": "P78527"
}
}
],
"assay": [
{
"Text": "copptby"
}
]
}
}
],
"Volume": "7",
"FullJournalName": "PLoS ONE",
"Authors": "Ito Y, Ito T, Karasawa S, Enomoto T, Nashimoto A, Hase Y, Sakamoto S, Mimori T, Matsumoto Y, Yamaguchi Y, Handa H",
"Issue": "12",
"Pages": "e50481",
"PMCID": "3515620"
}
In the above example, the "Datums" field has only one subdocument, but usually, the "Datums" field will have around 20-30 subdocuments. I want my MongoDB query to output documents (that satisfy certain criteria), where the "Datums" field will have unique subdocuments in its array. To do that I am using the following MongoDB query:
db.My_Datums.aggregate(
[
{ "$match": {
"Datums":
{
"$elemMatch":
{
"map.treatment.Entity.uniprotSym": { "$in": ["P33981", "P78527"] },
"map.assay.Text": "copptby"
}
}
}},
{ "$project": { "PMCID":1, "Title":1, "PubDate":1, "Volume":1, "Issue":1, "Pages":1, "FullJournalName":1, "Authors":1, "Datums.map.assay.Text":1, "Datums.map.change.Text":1, "Datums.map.subject.Entity.strings":1, "Datums.map.treatment.Entity.uniprotSym":1, "Datums.evidence_id":1, "_id":0 }},
{ "$unwind": "$Datums" },
{ "$match": { "Datums.map.treatment.Entity.uniprotSym": { "$in": ["P33981", "P78527"] }, "Datums.map.assay.Text": "copptby" }},
{ "$group": { "_id": "$PMCID", "Datums": { "$addToSet": "$Datums" }}}
]
#{ allowDiskUse: 1 }
)
But on running the above command, I am getting the below output:
{u'Datums': [{u'evidence_id': u'3515620_6',
u'map': {u'assay': [{u'Text': u'copptby'}],
u'change': [{u'Text': u'increased'}],
u'subject': [{u'Entity': {u'strings': u'dna-pkcs'}}],
u'treatment': [{u'Entity': {u'uniprotSym': u'P78527'}}]}},
{u'evidence_id': u'3515620_6',
u'map': {u'assay': [{u'Text': u'copptby'}],
u'change': [{u'Text': u'increased'}],
u'subject': [{u'Entity': {u'strings': u'dna-pkcs'}}],
u'treatment': [{u'Entity': {u'uniprotSym': u'P78527'}}]}},
{u'evidence_id': u'3515620_6',
u'map': {u'assay': [{u'Text': u'copptby'}],
u'change': [{u'Text': u'increased'}],
u'subject': [{u'Entity': {u'strings': u'dna-pkcs'}}],
u'treatment': [{u'Entity': {u'uniprotSym': u'P78527'}}]}}],
u'_id': u'3515620'}
What I am not understanding is why addToSet adding duplicate subdocuments to "Datums". Is there any way I can filter out the duplicates? What am I doing wrong in my query? I have searched a lot and read up a lot, but couldnt find any solution. Any MongoDB guru out there who could help this noob?? I will be eternally grateful to you!
Thanks in advance!
Here's our node configuration:
{
"run_list": [
"recipe[apt]",
"recipe[build-essential]",
[
"rackbox"
]
],
"rackbox": {
"jenkins": {
"job": "job1",
"git_repo": "https://github.com/hayesmp/railsgirls-app.git",
"command": "bundle exec rake",
"ip_address": "192.237.181.154",
"host": "subocean-southerner"
},
"ruby": {
"versions": [
"2.0.0-p247"
],
"global_version": "2.0.0-p247"
},
"apps": {
"unicorn": [
{
"appname": "app1",
"hostname": "app1"
}
]
},
"db_root_password": "iloverandompasswordsbutthiswilldo",
"databases": {
"postgresql": [
{
"database_name": "app1_production",
"username": "app1",
"password": "app1_pass"
}
]
}
}
}
I'm just not sure where to insert the build essential compiletime = true attribute for my configuration.
This is the sample code for this stack overflow post: Chef: Why are resources in an "include_recipe" step being skipped?
name "myapp"
run_list(
"recipe[build-essential]",
"recipe[myapp]"
)
default_attributes(
"build_essential" => {
"compiletime" => true
}
)
Paste this into your node configuration:
"build_essential": {
"compiletime": true
}
BTW: you should use recipe[rackbox] instead of [rackbox] in your run_list