text:
Add support for distributed deployments with multiple daemons

Adds support for a new deploy.machine key to the dataflow YAML format.

Can be specified for individual nodes or for the whole dataflow.
Dataflows can be split across multiple machines/daemons.
If not set, the machine ID defaults to the empty string.

The dora daemon supports a new --machine-id argument, defaulting to the empty string. Multiple daemons can be connected to a coordinator, as long as they have different machine IDs.
The dora coordinator supports a new --port argument to change the port that the coordinator listens on. Defaults to 53290.
The dora daemon supports a new --coordinator-addr argument to set the IP and port number of the coordinator. Defaults to 127.0.0.1:53290.
Nodes will synchronize their start across machines through new  coordinator messages. Similarly, the coordinator will forward outputs and InputClosed events between machines.

I think there is a lot of good ideas in this PR, so thanks Philipp!
I think that we maybe lacking a file-system management piece of software to manage file between machines but also changes. I was looking at the implementation of cargo and how it manages cargo.lock and git-rs and I wonder if there is thing we can salvage or even use cargo to manage our user-defined nodes.
I will test it maybe further later during the day.

Yeah, we still need some kind of deploy functionality to get the nodes and operators from the CLI machine to the target machines. We already support URL sources for nodes and operators,

I think that we maybe lacking a file-system management piece of software to manage file between machines but also changes.

Agreed. There are currently only two options to distribute the node/operator binaries across machines:

Copy them manually, or through some custom script.
Use URL sources for nodes and operators, e.g. a GitHub release.

I think the second option is already quite convenient for "finished" nodes and operators, but it's cumbersome during development. We should try to make the edit->compile->deploy cycle easier for distributed dataflows too.
Maybe we could make the CLI send the executables via TCP as part of the spawn command? The receiving daemon could store them to the file system and then run them. This would make things much easier for nodes/operators written in Rust, as you could just develop as usual on the CLI machine and the dora start command would take care of everything else. For Python, we probably need some way to copy additional files, and set up a correct environment too...

I implemented the points discussed in the latest meeting and merged the latest changes from main. I think this PR is ready to be merged now. Please let me know if you have any other concerns.

authors: haixuanTao phil-opp

repo: dora-rs/dora


text:
typescript-vue-apollo's lazy query variables should be optional

Which packages are impacted by your issue?
@graphql-codegen/typescript-vue-apollo
Describe the bug
vue-apollo's lazy query allows to specify a query and only later execute it with a returned load function. That load function also allows overriding the GraphQL variables for the query. In turn, the variables don't have to be specified in the original useLazyQuery function: https://github.com/vuejs/apollo/blob/v4.0.0-beta.11/packages/vue-apollo-composable/src/useLazyQuery.ts#L10
In @graphql-codegen/typescript-vue-apollo however, the variables parameter is not optional.
Your Example Website or App
https://stackblitz.com/edit/github-wmnv5d?file=main.ts
Steps to Reproduce the Bug or Issue

Create a GraphQL query with only non-nullable variables.
Generate types with @graphql-codegen/typescript-vue-apollo
The generated useFooLazyQuery has a required parameter variables.

Expected behavior
The variables parameter should be optional, since the variables could be passed later into the returned load function. See https://stackblitz.com/edit/github-wmnv5d?file=main.ts
Screenshots or Videos
No response
Platform

OS: Linux
NodeJS: 18.17.1
graphql version: 15.8.0
@graphql-codegen/typescript-vue-apollo version: 4.0.0

Codegen Config File
import { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  schema: 'schema.graphql',
  documents: 'document.graphql',
  generates: {
    'types.ts': {
      plugins: ['typescript', 'typescript-operations', 'typescript-vue-apollo'],
    },
  },
};

export default config;

Additional context
No response

I'm facing the same issue.

source: gharchive/issue

authors: FloEdelmann Javey

license: MIT

license_type: permissive

license_source: github-api


text:
When fragment is the same type is omitted

Describe the bug
A clear and concise description of what the bug is.
When fragment is the same type is omitted
But __typename does not work properly
To Reproduce
Steps to reproduce the behavior:

Use '...' as schema
Use '...' as documents

fragment x on X{
    ...a
    ...b
}

fragment a on A{
    p
}

fragment b on B{
    p
}

Run the following command: gql-gen ...

Expected behavior
A clear and concise description of what you expected to happen.
export namespace X {
  export type Fragment =
    | A.Fragment
    | B.Fragment
}

*** Output ***
export namespace X {
  export type Fragment =
    | A.Fragment
}

Schema/Documents
If possible and relevant, please provide your GraphQL schema and GraphQL documents.
Environment:

OS:
Codegen:
Node:

Additional context
Add any other context about the problem here.

I think we fixed it during the refactor (still WIP): https://github.com/dotansimha/graphql-code-generator/pull/1353
To make sure, can you please provide a schema matches your types? are you using interfaces or unions for the fragment matching?
Also, can you please provide an example of the output you are expecting?

expecting:
export namespace X {
  export type Fragment =
    | A.Fragment
    | B.Fragment
}

Fix available in 1.0.0 👍

authors: dotansimha kgtkr

repo: dotansimha/graphql-code-generator


text:
Need update dependence called  @graphql-tools/prisma-loader to 8.0.2 for addressing vulnerabilities in jose v4.14.4

Is your feature request related to a problem? Please describe.
The @graphql-codegen/cli v5.0.2 use  @graphql-tools/prisma-loader to 8.0.1 which use jose v4.14.4.
There is vulnerabilities on jose v4.14.4 which is used by @graphql-tools/prisma-loader to 8.0.1.
Please see this alert => https://github.com/advisories/GHSA-hhhv-q57g-882q
Describe the solution you'd like
We need update  @graphql-tools/prisma-loader to v8.0.2 to use jose v5 which is already vulnerabilities addressed
Describe alternatives you've considered
No response
Is your feature request related to a problem? Please describe.
No response

It was simply a matter of updating the prisma-loader. My apologies.


text:
[graphql-request] expose operationType to SdkFunctionWrapper

Description
@charlypoly This PR simply exposes the operationType to graphql-request middlewares.
Related #7608

Type of change

[x] Minor improvement (non-breaking change which adds functionality)

Checklist:

[x] I have followed the CONTRIBUTING doc and the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

@charlypoly sorry for the oversight, I've updated the pertinent tests.

Thank you @Diizzayy, it has been released in @graphql-codegen/typescript-graphql-request@4.4.0

source: gharchive/pull-request

authors: Diizzayy charlypoly


text:
ISSUE-8844 - Resolving issue with nesting fields in provides directiv…

…e being prevented
🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Related # (issue) ISSUE-8844
This allows using of nested fields in the provides federated directive as mentioned in the related issue.
Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

Screenshots/Sandbox (if appropriate/relevant):
Adding links to sandbox or providing screenshots can help us understand more about this PR and take action on it as appropriate
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Unit Tested

Test Environment:

OS:
@graphql-codegen/...:
NodeJS:

Checklist:

[x] I have followed the CONTRIBUTING doc and the style guidelines of this project
[x] I have performed a self-review of my own code
[] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

thank you!

Hi @saihaj, When you will be publishing a version with these changes?

Hi @saihaj, When you will be publishing a version with these changes?

we are finalizing a few more things so will try to get this patched up Monday/Tuesday next week

Ok, thanks for that, we will be waiting for that.

Stuck with the same issue, Waiting for this change.

Hi @saihaj it is working now thanks a lot for your help.

authors: dannyuttarwar dlynam01 elbertcastaneda saihaj


text:
using old and unecessary --save flag on npm

[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 261c9875-3db6-4d30-f9d6-922a9334ecb2
Version Independent ID: b8f8f7c4-9c90-869d-9fd7-a887bc28f262
Content: Use the React project template with ASP.NET Core
Content Source: aspnetcore/client-side/spa/react.md
Product: aspnet-core
Technology: aspnetcore-clientside
GitHub Login: @SteveSandersonMS
Microsoft Alias: scaddie

Moved to Container issue: Use the React project template #16209

authors: Rick-Anderson mmouhib


text:
Explain partition key for rate limiting

Description
I'm using the partitioned rate limiter, which involves a "partition key" concept. Unfortunately, that's not explained anywhere.
After trial-and-error I realised:

for incoming requests: it allows for policies-per-users, e.g. partitioned by username, IP address, access token
for outgoing requests to external APIs: one would probably use a constant partition key, e.g. "aws-sns-service", "azure-auth-service"

It would be helpful to add a small explanation about this concept and how to use it.
Page URL
https://learn.microsoft.com/en-us/aspnet/core/performance/rate-limit?view=aspnetcore-8.0
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/performance/rate-limit.md
Document ID
bb96b20f-0991-d6de-4d98-192cd469460f
Article author
@tdykstra

After trial-and-error I realized: for incoming requests: it allows for policies-per-users, e.g. partitioned by username, IP address, access token

That's shown in a couple places.
ASP.NET Core rate limiting middleware goes into even more detail.
@Kahbazi @maartenba can be called in more info needed and backup @wtgodbe

I suspect the reason it was closed was the thought that the means for answering the question had been provided -- either by checking the referenced blog post or by asking one of the individuals tagged as resources if more information was needed.

authors: Rick-Anderson lonix1 tdykstra


text:
BlazorWebAppOidc sample: incorrect CookieOidcRefresher implementation

Description
CookieOidcRefresher expects an ID token from the token endpoint. This seems wrong, based on the spec, the Duende implementation and the fact that it always fails in my app.
Page URL
https://learn.microsoft.com/en-us/aspnet/core/blazor/security/blazor-web-app-with-oidc?view=aspnetcore-8.0&pivots=without-bff-pattern
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/security/blazor-web-app-with-oidc.md
Document ID
c3346d3a-346b-8db4-2650-ec044b3f0dd9
Article author
@guardrex
Related Issues

It looks like we need to determine whether the refresh token is really an ID token before indiscriminately reading claims from it. If it's not an ID token, we should probably just continue to use the old claims stored in the cookie. https://github.com/dotnet/aspnetcore/issues/58826 is also related to getting the right claims on refresh, but that's focused on refreshing claims from the /userinfo endpoint if it's enabled.

So ... @halter73 ... do you want to transfer this issue to the PU repo, or should @albi005 open a new PU issue on this?

In the meantime, I think it would make sense to add a comment to the sample/docs noting that the refresh implementation might need to be updated depending on the Identity Provider.

I can add whatever makes sense to add, but it's best if one of you who understands what the text should say write it in a comment here for publication, and then I'll edit it for style+grammar and place it in the article. If it should go in under a heading to help surface it in the article, give me proposed heading text as well.

Token refresh
The sample includes code in CookieOidcRefresher.cs showing how to update the user's claims automatically when they expire. The current implementation expects to receive an ID token from the token endpoint in exchange for the refresh token. This ID token is then used to overwrite the user's claims.
The sample implementation doesn't include code for requesting claims from the UserInfo endpoint on token refresh. Refer to the following issue for an example on how to do that: https://github.com/dotnet/aspnetcore/issues/58826#issuecomment-2492738142

[!NOTE]
Some identity providers only return an access token when using a refresh token^1. You should handle this as needed.

## Token refresh

The sample includes code in `CookieOidcRefresher.cs` showing how to update the user's claims automatically when they expire. The current implementation expects to receive an ID token from the token endpoint in exchange for the refresh token. This ID token is then used to overwrite the user's claims.

The sample implementation doesn't include code for requesting claims from the UserInfo endpoint on token refresh. Refer to the following issue for an example on how to do that: https://github.com/dotnet/aspnetcore/issues/58826#issuecomment-2492738142

> [!NOTE]
> Some identity providers only return an access token when using a refresh token[^1]. You should handle this as needed.

[^1]: https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse

I think this should go above the "Cryptographic nonce" section.
@halter73 could you please check if this is correct?

Great ... I'm going to go ahead and update the PR with language closer to this.
We can take up the discussion over there on https://github.com/dotnet/AspNetCore.Docs/pull/34315.


text:
Update Node.js version

Fixes #23309
Does this work for you, @bobbytreed?
Brennan: Please see the issue for Bobby's remarks, which pertain to Azure SDK and not ASP.NET Core, per se.

@BrennanConroy ... You're still aware of this, right? I don't think that there's any rush on it. See the issue convo for details when you reach it.

@bradygaster ... Do you have a sec to look at this? ... See the issue explains the reason for this need at ...
https://github.com/dotnet/AspNetCore.Docs/issues/23309

sorry just saw this was out of the office -

authors: bradygaster guardrex


text:
Confusing, unclear where to put the code

[Enter feedback here]
Confusing, unclear where to put the code.
For all the pages about loading related data it is not clear where the code should be placed in which program.
I seem to be puting it in the wrong places because of all the errors I get attempting to add to my site

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: cc261727-1ecd-5dcb-fb88-1b1762263789
Version Independent ID: a15c2f82-ebb7-9867-50ad-35f80366528f
Content: Explicit Loading of Related Data - EF Core
Content Source: entity-framework/core/querying/related-data/explicit.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @roji
Microsoft Alias: avickers

@hcprobst can you be more specific, and possibly show a program of yours where you're putting the code in the wrong place? The code samples in that page can generally be used anywhere where one wants to execute a database query with EF Core.

Sorry, I think I have it now.
Thank you
Carey
Carey Probst  |  Application Developer
Information Technology Department
Lock Haven University
Smith Hall, B 2
401 North Fairview Street, Lock Haven, PA   17745
Phone: 570.484.3020 |  @.@.>  |  www.lockhaven.eduhttp://www.lockhaven.edu/
From: Shay Rojansky @.>
Sent: Thursday, October 6, 2022 1:23 PM
To: dotnet/EntityFramework.Docs @.>
Cc: Probst, Carey (hcp244) @.>; Mention @.>
Subject: Re: [dotnet/EntityFramework.Docs] Confusing, unclear where to put the code (Issue #4073)
This email originated from outside of LHU.
@hcprobsthttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhcprobst&data=05|01|hcp244%40lockhaven.edu|b743fb9ef5d140b40ce808daa7bf6edf|db0889bee72146d48e6d106992633b33|0|0|638006737897290013|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=jLyXwRrCsC35CHf0HPiOiZgQUZ0qCH3oljOz6nAMuoM%3D&reserved=0 can you be more specific, and possibly show a program of yours where you're putting the code in the wrong place? The code samples in that page can generally be used anywhere where one wants to execute a database query with EF Core.

Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2FEntityFramework.Docs%2Fissues%2F4073%23issuecomment-1270438049&data=05|01|hcp244%40lockhaven.edu|b743fb9ef5d140b40ce808daa7bf6edf|db0889bee72146d48e6d106992633b33|0|0|638006737897446249|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=HzNP2h2qFgDQUyxnuOU2x1ObvXR1mgRm1Kc0IcKIWh8%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA2AMMDGCQB35DUXQNCUMX7LWB4DHVANCNFSM6AAAAAAQ6ZN42Y&data=05|01|hcp244%40lockhaven.edu|b743fb9ef5d140b40ce808daa7bf6edf|db0889bee72146d48e6d106992633b33|0|0|638006737897446249|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=hh2sfymPQu6H8sYNrFAaWx2R7P1Ea%2BFNmLoYV4CM1U4%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.@.>>

authors: hcprobst roji


text:
Reference to vulnerable NuGet package System.Formats.Asn1

Describe the bug
The current version of Microsoft.Data.SqlClient has an (indirect) reference on a vulnerable NuGet package:
Microsoft.Data.SqlClient 5.2.2 -> System.Security.Cryptography.Cng 5.0.0 -> System.Formats.Asn1 5.0.0
To reproduce

Create a new netcoreapp3.1 project.
Add a reference to Microsoft.Data.SqlClient
Run dotnet list package --include-transitive --vulnerable

The output shows vulnerable package System.Formats.Asn1 5.0.0
Expected behavior
No deprecated package should be found.
Further technical details
Microsoft.Data.SqlClient version: 5.2.2
.NET target: netcoreapp3.1
SQL Server version: not relevant
Operating system: not relevant
Additional context
Related to https://github.com/dotnet/SqlClient/issues/2048

@DW-MaximV The minimum .NET version in Microsoft.Data.SqlClient v5.2.2 is .NET 6, so you cannot downgrade to an earlier version. If you insist on using .NET Core 3.1, you will need to use Microsoft.Data.SqlClient v3.1. However, please note that this version has some vulnerabilities, and we were unable to simply bump the major versions of dependencies due to semantic versioning reasons.

@JRahnama OK, I understand.

authors: DW-MaximV JRahnama

repo: dotnet/SqlClient


text:
Fix getting readonly column metadata

Fixes #275

LGTM

Ported to corefx in PR#42122


text:
Can the Torch.Save support object?

Hi,
According to the official design, torch.save can save the object state.
Can TorchSharp support it?
https://pytorch.org/docs/stable/generated/torch.save.html
Because I need to save extra information.
https://github.com/DLR-RM/stable-baselines3/blob/f3abda5cbc9dab71fbda44d9feca7efd7bb09dfe/stable_baselines3/common/policies.py#L159

I know that because of the characteristics of C#, using Reflection to create instances will still encounter many problems.
Perhaps it is possible to design an interface that allows developers to choose which attributes need to be extracted

It cannot currently do so.

Will it be supported in the future?
Python has a pickle function library, which can easily save the state of the object
However, this seems to require support from the dotnet team. I think this feature is useful in the field of machine learning

Hi, According to the official design, torch.save can save the object state. Can TorchSharp support it? https://pytorch.org/docs/stable/generated/torch.save.html
Because I need to save extra information. https://github.com/DLR-RM/stable-baselines3/blob/f3abda5cbc9dab71fbda44d9feca7efd7bb09dfe/stable_baselines3/common/policies.py#L159

You could use the System.Text.JSON.JsonConverter  and when use public static void Save(this Tensor tensor, System.IO.BinaryWriter writer) as Nikolas explained. This would do the job of serialisation.

This should do the trick now you can make a class with Tensors in the Parameters and serialize this as Json.
       var options = new System.Text.Json.JsonSerializerOptions();
        options.Converters.Add(new TensorConverter());
        var data = System.Text.Json.JsonSerializer.Serialize(this, options);

using System.Text.Json;
using static TorchSharp.torch;
using TorchSharp;
using System.IO;
namespace Docker.Visual
{
public class JsonTensor
{
public long[] _shape { get; set; }
public  ScalarType _type { get; set; }
public byte[] data { get; set; }
public bool requires_grad { get; set; }
public string[] names { get; set; }
}
public class TensorConverter : System.Text.Json.Serialization.JsonConverter<Tensor>
{

    public override Tensor Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var txt = reader.GetString();
        var jt = (JsonTensor) System.Text.Json.JsonSerializer.Deserialize(txt, typeof(JsonTensor));
        var tensor = torch.empty(jt._shape, dtype: jt._type, requires_grad: jt.requires_grad, names:jt.names);
        using (var s = new MemoryStream(jt.data))
        { tensor.Load(new BinaryReader(s));}
        return tensor;
    }

    public override void Write(Utf8JsonWriter writer, Tensor value, JsonSerializerOptions options)
    {
        using (var s = new MemoryStream())
        {
            using (var w = new BinaryWriter(s))
            { value.Save(w);}
            var jt =new JsonTensor() { data = s.ToArray(), _shape = value.shape, _type = value.dtype , names = value.names , requires_grad = value.requires_grad};
            var _o = new System.Text.Json.JsonSerializerOptions();
            var data = System.Text.Json.JsonSerializer.Serialize(jt, _o);
            writer.WriteStringValue(data);
        };
    }
}

}

There's also a 'bytes' read/write property on Tensor that allows you to get the byte array of the Tensor. That's what the Tensor.Save()/Load() methods use for serialization.

Ok Nicklas. Its updated.

Can the JsonConverter not take a Span as input? That's too bad, if that's the case, because the bytes.ToArray() call will make a copy.

Niklas. Ok i cannot serialize pointers right now. Maybe Microsoft knows how to do this. :-) Some cloud based rent a pointer business model.

Fair enough. I guess the performance of serialization isn't super-critical, it's not likely something you do for every batch, for example. Probably no more than once every epoch.

This should do the trick now you can make a class with tensors in the parameters and serialize this as Json.
` public class JsonTensor { public long[] _shape { get; set; } public ScalarType _type { get; set; } public byte[] data { get; set; } public bool requires_grad { get; set; } public string[] names { get; set; } }
public class TensorConverter : System.Text.Json.Serialization.JsonConverter<Tensor>
{

    public override Tensor Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var txt = reader.GetString();
        var jt = (JsonTensor) System.Text.Json.JsonSerializer.Deserialize(txt, typeof(JsonTensor));
        var tensor = torch.empty(jt._shape, dtype: jt._type, requires_grad: jt.requires_grad, names:jt.names);
        tensor.bytes = jt.data;
        return tensor;
    }

    public override void Write(Utf8JsonWriter writer, Tensor value, JsonSerializerOptions options)
    {
            var jt =new JsonTensor() { data = value.bytes.ToArray(), _shape = value.shape, _type = value.dtype , names = value.names , requires_grad = value.requires_grad};
            var _o = new System.Text.Json.JsonSerializerOptions();
            var data = System.Text.Json.JsonSerializer.Serialize(jt, _o);
            writer.WriteStringValue(data);
    }
}`

If the property in the object is still an object. Then defines him as the parent class when writing the code.

Ok I maybe do not get the question. But now you can write something like this:
`
public string Serialize()
{
var options = new System.Text.Json.JsonSerializerOptions();
options.Converters.Add(new TensorConverter());
var data = System.Text.Json.JsonSerializer.Serialize(this, options);
return data;
}
    public IVisual Deserialize(string json)
    {
        var options = new System.Text.Json.JsonSerializerOptions();
        options.Converters.Add(new TensorConverter());
        return (IVisual)System.Text.Json.JsonSerializer.Deserialize(json, this.GetType(), options);
    }

`

@NiklasGustafsson @Sprinzl,
I think BinaryFormatter is the most suitable for my needs, he is very close to python's pickle, but he seems to be deprecated.
https://learn.microsoft.com/zh-tw/dotnet/api/system.runtime.serialization.formatters.binary.binaryformatter?view=net-7.0
https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md

Hi @NiklasGustafsson,
I have my code serializable by system.text.json, but I need to pass JsonSerializerOptions to JsonSerializer.Serialize and JsonSerializer.Deserialize.

If you are using JSON (including BSON), I would suggest using the Newtonsoft,Json package: https://www.nuget.org/packages/Newtonsoft.Json

Why use Newtonsoft instead of system.text.json

Hi @NiklasGustafsson,
My code supports serialization using newtonsoft. But I need to pass JsonSerializerSettings to JsonSerializer.
        Newtonsoft.Json.JsonSerializer jsonSerializer = Newtonsoft.Json.JsonSerializer.Create(newtonsoftSerializerOptions);
        using MemoryStream ms = new();
        using BsonDataWriter writer = new(ms);
        jsonSerializer.Serialize(writer, space);
        ms.Position = 0;
        using BsonDataReader reader = new(ms);
        Box? box = jsonSerializer.Deserialize<Space>(reader) as Box;

Hi @NiklasGustafsson, My code supports serialization using newtonsoft. But I need to pass JsonSerializerSettings to JsonSerializer. Thank you.
Newtonsoft.Json.JsonSerializer jsonSerializer = Newtonsoft.Json.JsonSerializer.Create(newtonsoftSerializerOptions);
using MemoryStream ms = new();
using BsonDataWriter writer = new(ms);
jsonSerializer.Serialize(writer, space);
ms.Position = 0;
using BsonDataReader reader = new(ms);
Box? box = jsonSerializer.Deserialize<Space>(reader) as Box;

BsonDataWriter and BsonDataReader  moved to https://www.nuget.org/packages/Newtonsoft.Json.Bson/1.0.2

Ok just have a helper with an extension and you have no problem with always rewrite.
public static void Write(this string path, object object) ….
public static string Local(this string path)…
Now you can write @“Data/xxx.json”.Local().Write(object)
This is as simple as it gets.

What does it mean?

you have no problem with always rewrite.

Umm...
I still prefer BinaryFormatter, not all objects can be quickly serialized using Newtonsoft.Json

authors: ChengYen-Tang NiklasGustafsson Sprinzl

repo: dotnet/TorchSharp


text:
Using v1 pattern in url for minimal API .NET 6 versioning

Hi
I want to use /v1/orders or /v2/orders pattern using api versioning
Well, I configured like:
var builder = WebApplication.CreateBuilder(args);
ApiVersion apiV1 = new ApiVersion(1);
ApiVersion apiV2 = new ApiVersion(2);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddApiVersioning(opts =>
{
    opts.ReportApiVersions = true;
    opts.ApiVersionReader = new UrlSegmentApiVersionReader();
}).AddApiExplorer(opts =>
{
    opts.GroupNameFormat = "'v'VVV";
    opts.SubstituteApiVersionInUrl = true;
});

builder.Services.AddTransient<IConfigureOptions<SwaggerGenOptions>, ConfigureSwaggerOptions>();
builder.Services.AddSwaggerGen();

// other DI calls

var app = builder.Build();
var orderApiSet = app.NewApiVersionSet("Orders").Build();

app.MapGet("/orders", async ([FromServices] IOrdersRepository orderRepo) =>
{
    return await orderRepo.ListAsync(...);
}).WithApiVersionSet(orderApiSet)
  .HasApiVersion(apiV1);

app.MapGet("/orders", async ([FromServices] IOrdersRepositoryV2 orderRepo) =>
{
    return await orderRepo.List1Async(...);
}).WithApiVersionSet(orderApiSet)
  .HasApiVersion(apiV2);

app.UseSwagger();
app.UseSwaggerUI(opts =>
{
        var descriptions = app.DescribeApiVersions();
        foreach (var desc in descriptions)
        {
            var url = $"/swagger/{desc.GroupName}/swagger.json";
            var name = desc.GroupName.ToUpperInvariant();
            opts.SwaggerEndpoint(url, $"Orders API {name}");
        }
});

await app.RunAsync();

I expected if type in url like /v1/orders that would go to first MapGet but I got 404 page. As well as for /v2/orders
If I type /orders without any vX then I got 400 that api version is not specified.
How to solve this ?
A solution would be  app.MapGet("v{version:apiVersion}/orders") but in SwaggerUI displays like:

But is not quite good because I already selected api version from top right corner dropdown, don't see the purpose of {version} in call

Thanks for reporting this. There are lot of possible setup variations and I hadn't tried this one. There is a bug in ASP.NET Core's implementation of the API Explorer for Minimal APIs that is causing this. I've reported it so we'll see what they say. API Versioning relies on the ApiParameterDescription being discovered and populated so that it can match it up for substitution. The parameter is not discovered so there is nothing to match.
In the meantime, there are a few possible workarounds. The best option at the moment would probably be to use a custom IOperationFilter in Swashbuckle and perform the substitution yourself. That will be predicated on using the same route parameter name in your templates (e.g. {version}, but you define it).

The ApiDescription.GetApiVersion() extension method with get you the associated ApiVersion
ApiVersion.ToString can then be called using ApiExplorerOptions.SubstitutionFormat to get the substitution value
Replace {version} (or appropriate token) in ApiDescription.RelativePath

This effectively the same steps API Versioning uses. Without a match parameter though, there's no way to accurately know how to generate the {<name>} token for substitution.

The ASP.NET Core team confirmed the bug, but they've yet to provide any feedback as to when the fix might be published. I'm getting the impression that it may not happen until .NET 7.0. It's a pretty glaring oversight IMHO and should be included in a service release. The bug affects more than just API Versioning.
Regardless, I've come up with a way to work around the problem and hide the internal yuckiness of it. It's a sticking point for me that the fix should not result in a change (e.g. breaking change) to API Versioning's public API surface. It's not the ideal solution, but I've got something working that will make this scenario work without exposing the bits that will likely go away in a future patch or version of ASP.NET Core.
Expect to see this fixed in the next release.

var descriptions = app.DescribeApiVersions();

@knightian is that a question? Looks like you are probably missing a using directive. The recommended statements are:
using Asp.Versioning;
using Asp.Versioning.Conventions;

@knightian is that a question? Looks like you are probably missing a using directive. The recommended statements are:
using Asp.Versioning;
using Asp.Versioning.Conventions;

Entire Asp.Versioning.ApiExplorer was not even added to my project by nuget. Seems it needed to be manually added.

Yeah, it's unfortunate, but the much of the implementation for the API Explorer (Microsoft.AspNetCore.Mvc.ApiExplorer) depends on Microsoft.AspNetCore.Mvc.Core. I'm not entirely sure why that is, but it's a decision that was made years ago and can't easily change. The core abstractions - Microsoft.AspNetCore.Mvc.Abstractions - is part of the MVC Core surface area, but doesn't have a dependency on the Microsoft.AspNetCore.Mvc.Core.
I considered attempting to split the two apart, but it wasn't buying much value. I did move the abstractions into Asp.Versioning.Http, which is the bare requirement for Minimal APIs. I also didn't want to repeat the mistakes of the ASP.NET team will reimplemented some API Explorer implementation and missed supported use cases. I purposely kept Mvc in the name so there is a way to break things a part in the future if it ever makes sense. For this particular use case, there really isn't any MVC being used. Since the ASP.NET Core model is a now a FrameworkReference as opposed to individual packages, it shouldn't be of any concern; however, I did try to keep things as isolated as possible.
There are arguably a few things under the MVC name that aren't really MVC. Term Web API is still used even though it's branded under MVC. If Swagger/OpenAPI would have been more mature - say 5+ years ago, I think you might have seen things unfold and be named differently. I hope that helps clear things up.

6.0 has been officially released and contains the workaround. In terms of the original question, that should address it. I can't control when the ASP.NET Core will eventually provide a fix, but once they do, I'll integrate it. That change should be transparent to API Versioning consumers.
There are some additional improvements for .NET 7 that should allow declaring an ApiVersion parameter, which might help. We'll have to see.
Thanks for reporting the issue and the discussion. If somehow this did not solve your problem, I'm happy to reopen the issue and discuss further.

@jamesfoster This is happening because you are missing the route constraint. You have:
[Route("/v{apiVersion}")]

but it needs to be:
[Route("/v{version:apiVersion}")]

apiVersion is the default name of the ApiVersionRouteConstraint. This can be changed via ApiVersioningOptions.RouteContraintName, but I don't think I've seen anyone actual do it. The name is used by infrastructure so the option to configure it ensures they keep in lock-step.
You can name the route parameter whatever you want. In the example it's version, but it can be anything you like (e.g. apiVersion, ver, etc).
Also note that the name ListCountryCodesController_v2 is against the expected naming convention. It's expected to have the form ListCountryCodes2Controller. The default naming convention that ASP.NET Core uses assumes the name will be [Name]Controller. API Versioning extends this convention to be [Name][#]Controller. If you go off convention, it may break collation because it happens by name. Applying [ControllerName("<name>")] or swapping out the IControllerNameConvention service are alternate ways to give yourself more flexibility in type names.

Thanks, that worked. Much appreciated. I realised the name of the controller was causing it not to be picked up. I'm probably going to organise the files in folders/namespaces by version. Thanks so much for your help.

@commonsensesoftware Hi there sorry to disturb, I seem to be running into the same issue as above.
I am running a dotnet7 minimal-api project with swagger and all my urls show "v{version}" in the url.
Problem is that with minimal api I use "AddEndpointsApiExplorer" instead of "AddApiExplorer" which means i can;t set the option for the quick fix you've implemented, is there any guidance you can give on how to work around this using the minimal API

You are absolutely right, thanks...  small distinctions make a big difference.. as always.. Many thanks for the quick reply..

authors: Sonic3R commonsensesoftware djrietberg jamesfoster knightian

repo: dotnet/aspnet-api-versioning


text:
fix broken link

This is another topic that contains a link to the dotnet-apiport repo docs

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/porting/libraries?branch=pr-en-us-1166

Status: Succeeded.
Open Publishing Report.

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/porting/libraries?branch=pr-en-us-1166

Status: Succeeded.
Open Publishing Report.

@mairaw LGTM

authors: mairaw qinezh rpetrusha

repo: dotnet/core-docs


text:
Treat warning as error (.Net Core Project)

Treat warning as an Error (.Net Core Project)
General
Is not an issue, but maybe a new feature when we were building
I would like to see an option that I can set a warning as an error in my .net core project.
Will be perfect!

Are you familiar with the TreatWarningsAsErrors msbuild property? Would that work for your use case?

@shpsyte the suggestion given by @omajid is probably what you're looking for.
I'm closing this issue as resolved, but feel free to reopen it if you have more questions, we'll be happy to help.

authors: carlossanlop omajid shpsyte

repo: dotnet/core


text:
This software needs to be updated. Contact the developer for more information.

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install
Operating System: macOS
Provide details about the problem you are experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.
dotnet-sdk-3.0.101-osx-x64.pkg” can’t be opened because Apple cannot check it for malicious software.
It is not updated to the latest macOS Catalina software update.

Can you provide your exact OS version and the commands you're using to install the SDK? Thanks.
CC @aik-jahoda

Having same issue while trying to download dotnet-sdk-3.0.101-osx-x64.pkg
OS Version: Catalina v. 10.15.1
just following these install guides: https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.0.101-macos-x64-installer and getting the above error message

There's a workaround and more info posted here: https://github.com/dotnet/core/issues/3685#issuecomment-547411254

Show the file in the Finder and open context menu by right click on the downloaded package. Then select Open and a similar dialog will appear however there will be Open button available. When you open it in this way it will execute the package.

@leecow @jcagme do we currently expect this issue to be popping up? Is it documented in a place people can find? Context: "dotnet-sdk-3.0.101-osx-x64.pkg can’t be opened because Apple cannot check it for malicious software." I see a lot of discussion online for other software installers that need this workaround, but people will naturally ask us when our instructions lead them down this path.
/cc @aik-jahoda

Still having this issue when downloading .NET Core SDK 3.1.100: https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.1.100-macos-x64-installer
macOS 10.15.1 (19B88)

@gastonmuijtjens Did you follow https://github.com/dotnet/core/issues/3943#issuecomment-560578020 comment? If it doesn't help, can you share your error message and os version?

This message is occurring due to new security features in Catalina. We have been working with Apple to understand what needs to be done and are working toward a resolution. This will take place over the next few months for 2.1, 3.0 and 3.1. See the 3.1 Known Issues document for more info on installing on Catalina if you get this error.

Still happening here. Seriously, anyone have tried this before releasing such an important package? Catalina has been around for months now....

I tested it on Catalina and it works fine. You need to follow this comment https://github.com/dotnet/core/issues/3685#issuecomment-547411254 ?

Show the file in the Finder and open context menu by right click on the downloaded package. Then select Open and a similar dialog will appear however there will be Open button available. When you open it in this way it will execute the package.

It works following https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1-known-issues.md#net-core-installation-on-macos-catalina-1015
But it is annoying that such a distribution does not work out of the box.

thanks @aik-jahoda  - right clicking  on file and open worked for me anyway on Catalina.

In order to install Package.dmg on Big Sur, you have to do it by the command line.

Open the Package.dmg
Open the console and type:
sudo /usr/sbin/installer -pkg  -target /

authors: ColCoutts DavosMarsh MariaFL9815 aik-jahoda andreacassioli dagood eshorr-cyber gastonmuijtjens leecow scalablecory


text:
Dockerfile FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build - Wrong version

Problem encountered on https://dotnet.microsoft.com/learn/aspnet/microservice-tutorial/docker-file
Operating System: windows
Is this supposed to be version 3.1 instead? I ran into issues when running the doctor build command. After altering this file to 3.1 I no longer had these issues. It specifically says in the myMicroservice.csproj file <TargetFramework>netcoreapp3.1</TargetFramework>
Not sure if this needs corrected or just something with my personal environment. Thanks!

The tutorial seems to be correct now.


text:
Erro: Não foi possível localizar um projeto para executar. Verifique se existe um projeto em C:\Users\xxx ou passe o caminho para o projeto usando --project.

Problem encountered on https://dotnet.microsoft.com/pt-br/learn/dotnet/hello-world-tutorial/run
Operating System: windows
A mensagem de erro é: "Não foi possível localizar um projeto para executar. Verifique se existe um projeto em C:\Users\Meu User ou passe o caminho para o projeto usando --project."
Como passo para --project? A instalação foi bem sucedida.

Oi, @giulia-donato
Tive o mesmo problema que você em um outro contexto e resolvi com o seguinte comando:
dotnet run --project <Caminho_Até_O_CS.PROJ_Desde_A_Raiz>

Para exemplificar, o caminho que passei na íntegra do meu comando:
dotnet run --project .\Automations\Automations.csproj

Suponho que a sua IDE, por alguma razão, não está identificando o arquivo .csproj para rodar a aplicação. Ainda assim, é possível "forçar" essa identificação e, consequentemente, rodar a aplicação com o uso da flag --project

authors: giulia-donato matheusarb


text:
perfcollect does not process nolttng flag correctly

In a system without lttng ./perfcollect collect sampleTrace -nolttng errors out with "LTTng not installed. Install LTTng to proceed."
This is because in the script EnsurePrereqsInstalled comes before ProcessArguments has a chance to set useLTTng=0
workaround: sed -ie 's/useLTTng=1/useLTTng=0/' perfcollect

hmm I see someone has already sent a PR fixing this https://github.com/dotnet/corefx-tools/pull/75

repo: dotnet/corefx-tools

license: mit

license_source: bigquery


text:
Adding comment to field names that cannot be changed for compatibility with desktop .NET as they appear in serialization payload.

@jkotas @gkhanna79

Hi @SGuyGe, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

LGTM. Thanks!

authors: SGuyGe dnfclas jkotas

repo: dotnet/corert


text:
open statements

"open Microsoft.Azure.Storage" does not work for me.
"open Microsoft.WindowsAzure.Storage" seems correct.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 114a6d66-f77b-19a9-4e0d-ff46ced10228
Version Independent ID: 60721783-7fa5-aed0-d823-3935ebc90b7b
Content: Get started with Azure Table storage using F#
Content Source: docs/fsharp/using-fsharp-on-azure/table-storage.md
Product: dotnet-fsharp
GitHub Login: @sylvanc
Microsoft Alias: phcart

https://github.com/Azure/azure-storage-net/blob/master/Common/changelog.txt#L27

Changes in 10.0.0:

All: Namespace change from Microsoft.WindowsAzure.Storage.* to Microsoft.Azure.Storage.*, required for SxS with pre-9.4 versions of the library.

I'm not much sure, but I think the error in the article is in the following:

Next, use a package manager such as Paket or NuGet to install the WindowsAzure.Storage package and reference WindowsAzure.Storage.dll in your script using a #r directive. Do it again for Microsoft.WindowsAzure.ConfigurationManager in order to get the Microsoft.Azure namespace.

Did you try to install the following packages instead of WindowsAzure.Storage ?
Microsoft.Azure.Storage.Blob
Microsoft.Azure.Storage.File
Microsoft.Azure.Storage.Queue

/cc @cartermp , It seems that samples were updated in https://github.com/dotnet/samples/commit/eccca4a815bc89fca7bda79f1cbd9af682aeb1dc#diff-a9b38563f46b3c319a05f92eaa68242b but the article wasn't.

Yeah, it seems that the package reference should also be updated. @cartermp would know for sure.

authors: Youssef1313 johnalgo mairaw

repo: dotnet/docs


text:
.NET Core 2.1 is no longer supported.

Needs some update

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b01848ba-0d62-c070-ee2a-9b43e3966985
Version Independent ID: 0dadd1f3-1d08-37e1-2215-b8ea40b49c0c
Content: Migrate to ASP.NET Core 2.1
Content Source: docs/architecture/porting-existing-aspnet-apps/migrate-aspnet-core-2-1.md
Product: dotnet-architecture
GitHub Login: @ardalis
Microsoft Alias: nanil

@Rick-Anderson

Needs some update

What update does it need? This is a what's new for 2.1, so the content should still be accurate since 2.1 hasn't changed. Are you suggesting we retire the what's new docs for no-longer-supported versions, i.e., 2.0, 2.1, 2.2, and 3.0?

I would at least remove it from the TOC

It's true it's no longer supported and that will be updated in the revision coming imminently. However, it's still a reasonable incremental step for customers to take on the path to a supported version if they're coming from .NET Framework. As such, my intention is to leave the chapter but update the text and include some strong Note/Warning boxes indicating that the migration is meant to be an interim one only, as it is no longer a supported framework.

Fixed in https://github.com/dotnet/docs/pull/27512

This was merged into main - probably can be closed.

authors: Rick-Anderson ardalis tdykstra


text:
Clarify recommendation of async vs. task CE

In the linked docs ("What's new in F# 6"), in the section about the task CE, the document currently says:

In general, you should consider using task {…} over async {…} in new code if you're interoperating with .NET libraries that use tasks, and if you don't rely on asynchronous code tailcalls or implicit cancellation token propagation.

In Async programming in F#, section "Core concepts", it says:

In general, you should use async { } programming in F# unless you frequently need to create or consume .NET tasks.

While there is certainly some agreement between the two statements (the condition about interoperating with .NET tasks), I get the impression that the former generally instructs to prefer task, while the latter instructs to prefer async. This impression comes across to me strongly enough that I find it confusing and chose to raise this issue.
If the recommendation to use async in "Async programming in F#" is correct, I suggest rephrasing the quoted sentence from "What's new in F# 6" to have the same sentiment.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: e2dea170-a8f4-90f6-e578-e406fb43fef1
Version Independent ID: 885f9f09-d2ff-112c-6dda-9a31bccc0e8a
Content: What's new in F# 6 - F# Guide
Content Source: docs/fsharp/whats-new/fsharp-6.md
Product: dotnet-fsharp
GitHub Login: @cartermp
Microsoft Alias: dotnetcontent

ping @dsyme for recommendations on a proposed change.

@cmeeren Note the F# 6 guidance says:

...consider using task {…} over async {…} in new code if

you're interoperating with .NET libraries that use tasks, AND
you don't rely on asynchronous code tailcalls or implicit cancellation token propagation.

So I think that's saying that async is preferred in many "pure F#" coding situations.

Thanks! Note that with the updated phrasing (which seems identical between the two sources now), I still get the impression that it is generally preferable to use task.
For comparison, consider what happens if the phrasing is turned on its head:

In general, you should consider using async {…} over task {…} in new code unless you're interoperating with .NET libraries that use tasks and don't rely on asynchronous code tailcalls or implicit cancellation token propagation.

It technically says the same thing with respect to "pure F#" vs. interop coding situations, but the impression is now that async is preferred.
This may just be me, though. Feel free to close if you consider this a non-issue.

authors: BillWagner cmeeren dsyme


text:
New topic about API Analyzer

Background info: https://blogs.msdn.microsoft.com/dotnet/2017/10/31/introducing-api-analyzer/
/cc @terrajobst

@mairaw, I added a priority (P0), since I think that this topic is really important for porting. Feel free to change it if you disagree.

@OliaG, please work with @rpetrusha and @mairaw so this gets documented :-)

That's fine @rpetrusha. Especially because we won't be able to document all API compat and PNSE exceptions soon, so telling people about the analyzer would help.

@OliaG you're going to do this one right? Any idea when you'd like to address it? Then I can add the appropriate milestone.

Yes, I'm on it. Will do it this week.

authors: OliaG mairaw rpetrusha terrajobst


text:
WCF package references not added with version 1.0.0

I followed the instructions exactly, and I didn't see the following behavior (as mentioned under step 5):

The dotnet_svcutil tool also adds to the project the appropriate WCF packages required by the proxy code as package references.

I figured out that this only happens using the 1.0.0 version of the tool. The latest version available (1.0.2) indeed adds the WCS package references.
Under step 3, I think it is better to include a wildcard specifier for the patch level in the CLI tool reference:
<ItemGroup>
  <DotNetCliToolReference Include="dotnet-svcutil" Version="1.0.*" />
</ItemGroup>

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3d0bd854-fec8-fc4a-760a-42dc22e07f99
Version Independent ID: f04e9f8b-24d2-79fb-7521-6222c434e80f
Content: Microsoft WCF dotnet-svcutil tool
Content Source: docs/core/additional-tools/dotnet-svcutil-guide.md
Product: dotnet-core
GitHub Login: @mlacouture
Microsoft Alias: jralexander

@ralphhendriks, thanks for the feedback! @mlacouture, any thoughts?

@ralphhendriks, thank you for your feedback, I think you are right!  @JRAlexander, can we do that? thanks

Asking to close issue as the issue is now resolved in current MS documentation. @mlacouture

When I tried to run "dotnet svcutil http://contoso.com/SayHello.svc" from step 5 above, I got this error: Microsoft (R) WCF Service Model Proxy Generation Tool for .Net Core platform
[dotnet-svcutil, Version 1.0.4]
Copyright (c) Microsoft Corporation.  All rights reserved.
This tool collects information about how it is used in order to improve the tool. This functionality can be disabled by setting the environment variable "DOTNET_SVCUTIL_TELEMETRY_OPTOUT" to 1.
Attempting to download metadata from 'http://contoso.com/SayHello.svc' using WS-Metadata Exchange and HttpGet.
Error: Cannot obtain Metadata from http://contoso.com/SayHello.svc
If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address.  For help enabling metadata publishing, please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.
WS-Metadata Exchange Error
URI: http://contoso.com/SayHello.svc
The remote server returned an error: (404) Not Found.
If you would like more help, type "dotnet svcutil -h"

Hi @regal60740!
Thank you for trying the tool.  You need to use a real URI because the one in the documentation is 'assumed' to exist.

@JRAlexander, I don't seem to be able to close this issue, do you mind closing it? thanks,

Done!

I am getting following error when I try to execute dotnet svcutil --help/url/wsdl file or anyting.
Unable to generate deps.json, it may have been already generated.  You can specify the "-d" option before the tool name for diagnostic output (for example, "dotnet -d ": C:\Program Files\dotnet\sdk\2.2.104\Sdks\Microsoft.NET.Sdk\targets\GenerateDeps\GenerateDeps.proj

authors: JRAlexander Kexerval atifalibhatti mlacouture ralphhendriks regal60740


text:
Remove reference to "Future" in ML.NET docs

Summary
Removed the notion of future in the ML.NET documentation and added them to the list as they are now available.
Fixes #Issue_Number (if available)
https://github.com/dotnet/machinelearning/issues/4886
Preview Link: https://review.docs.microsoft.com/en-us/dotnet/machine-learning/automate-training-with-cli?branch=pr-en-us-18239

@aslotte when you get a chance, if you're comfortable with the changes I've suggested, can you please merge them into your branch so I can approve and merge this PR. Thanks!

@luisquintanilla how does that look?

@aslotte looks good. Sorry to make you take action though. Since the new version of the CLI is out, @briacht has made updates to this doc that reflect the latest experience. I'll close this PR for now and make sure your changes are included as part of her PR #18782 . Thanks again for the contribution!

authors: aslotte luisquintanilla


text:
Updated title of .NET Framework top-level migration topic

Updated title of .NET Framework top-level migration topic
For some reason that I don't understand, the correct title wasn't migrated from CAPS, although the remaining updated content was migrated.
Suggested Reviewers
@GuardRex @tompratt-AQ

Done.


text:
Create New Article

Submitted via Learn Editor.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: namanpatel6 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


text:
Poll for processes in connect mode

If collection rules are to be support for .NET Core 3.1 process or processes discovered via connect mode (dotnet-monitor reaches out to individual processes to establish diagnostic pipe connection), then process polling will need to be implemented. This will also require #49 to be completed in order to record which processes were already discovered in prior polling attempts.

It appears that rather than polling, the FileSystemWatcher can be used to discover when named pipes and Unix domain sockets are created and deleted. Polling can be added as a fallback for filesystems that do not support change notification.

repo: dotnet/dotnet-monitor


text:
Operation cancelled even on a good dataset after training fail

Step to reproduce:

regression training on this dataset (select price)
train fails because price can't be parse as single
select a good dataset, like taxi-fare-amount
train cancel, can only be solved if kill x64 process

trickyfile.txt

Yes I can confirm this is fixed! So happy!! 😄

authors: LittleLittleCloud beccamc

repo: dotnet/machinelearning-modelbuilder


text:
APEX fails in some LSP scenarios

I ran into the following problems while creating APEX tests for Razor

[x] Colorization is not returned from the editor.Classification.GetClassifications method. Failed test: Color
[x] OnTypeRename doesn't seem to work in the LSP scenario (but does work for HTML). Failed test: RazorOnTypeRename
[x] CodeAction lightbulbs don't appear in the LSP scenario. Failed test: RazorCodeActionCommandTest
[ ] AutoInsert sometimes fires twice in LSP scenarios, resulting in the relevant text appearing twice. Failed test: AutoInsertCSharp

We should follow up with them to find out more and drive a fix.

The first 3 items are fixed. The last item is PROBABLY fixed but it was flaky before so it's hard to say for certain.

repo: dotnet/razor-tooling


text:
Failed to sync client configuration on the server

This is just a warning, but getting this fairly frequently. Not sure if this is expected, but wanted to call it out.
[Warn  - 10:20:26 PM] OmniSharp.Extensions.LanguageServer.Server.Configuration.DidChangeConfigurationProvider: No ConfigurationItems have been defined, configuration won't surface any configuration from the client! |
[Warn  - 10:20:29 PM] Microsoft.AspNetCore.Razor.LanguageServer.DefaultRazorConfigurationService: Failed to sync client configuration on the server: System.OperationCanceledException: The operation was canceled.
   at System.Threading.CancellationToken.ThrowOperationCanceledException()
   at OmniSharp.Extensions.JsonRpc.ResponseRouter.ResponseRouterReturnsImpl.Returning[TResponse](CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Razor.LanguageServer.DefaultRazorConfigurationService.GetLatestOptionsAsync(CancellationToken cancellationToken) in /_/src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/DefaultRazorConfigurationService.cs:line 57 |

This is happening to me in Visual Studio 2022 GA as well as Preview.

authors: TanayParikh mohaaron


text:
Merge main into features/single-compiler-dll

Part of #8400.
Only commits after "Merge main into features/single-compiler-dll" contain changes (the merge commit itself has no changes).
The changes are mostly because there's a single test project now and

since https://github.com/dotnet/razor/pull/8435 the project references ASP.NET Core SDK, but some older tests rely on shims;
netfx / netcore mismatch (e.g., source generator tests were written only for netcore, so have to be disabled in netfx-flavor of the test project).

@dotnet/razor-compiler PTAL

@dotnet/roslyn-compiler @jaredpar PTAL

repo: dotnet/razor


text:
Fields and labels not correctly sized on Project Properties Debug tab

This is a regression for desktop projects:

Create a desktop console application and open the Debug property page:

What is that page...

Looks a whole lot of broken

This is probably multiple monitors with different DPIs, will investigate this week.

I've been unable to repro this - if you can repro this, can you list:
Resolutions of all screens
DPI of all screens

@srivatsn Do you have a repro for this?

No, I can't seem to repro it anymore. Tried various configurations.

I see this on a Dell XPS 15 9550 laptop running 384x2160 at 250%

With 15.0.0-RC.4+26206.0 and WPF project open.

Pulling this into 15.1 - there's bunch of VS Feedback around this. In https://developercommunity.visualstudio.com/content/problem/22367/vs-2017-rc-project-properties-window-debug-tab-con.html there's a MSFT person as well who can repro it. Can you try contacting them?

@srivatsn Hi, that was me. I do indeed have multiple monitors (2 1920x1200, 1 1080x1920). Not sure about DPI scaling settings. I'm seeing this in C# library projects, not in desktop apps.

@adammodlin Can you tell me exact monitors you are running?

@davkean Yes, here are the monitors (and the order they are daisy chained in case that matters):
Surface Pro 3 dock --> Dell U2415 --> Dell U2415 --> Dell P2414Hb.
They are all connected via DP or miniDP.

I've run into 5 more dupes on this on vsfeedback. We should prioritize this,

Seeing as I can repro this on my laptop, I thought I'd have a stab at pulling down the repo and firing it up. Any pointers on how the property pages work? Doesn't look like you're using the forms designer.

@flcdrg Thanks for the offer. The forms designer stopped opening when moved over to dogfood our repro in itself - we don't yet have WinForms support. I have an idea on what might be causing this - if I give you a branch to build can you test it?

Yes, happy to do that.
On 6 March 2017 at 11:05, David Kean notifications@github.com wrote:

@flcdrg https://github.com/flcdrg Thanks for the offer. The forms
designer stopped opening when moved over to dogfood our repro in itself -
we don't yet have WinForms support. I have an idea on what might be causing
this - if I give you a branch to build can you test it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/roslyn-project-system/issues/427#issuecomment-284277105,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXe686z--kD_5z875FVg-AMUWPiOEh4ks5ri1S5gaJpZM4Jx559
.

Same problem in latest VS update. 2560x1440

Is there any workaround?
14.0.0-RTW+26228.4

@flcdrg I have a PR out, can you pull that branch and see if this resolves your issue?

Taking a look now..

Confirmed at my end that Debug tab looks correct now.
FYI I'm also seeing the 'opposite' problem for the Build tab. In that case the tab is stretching too far and ending up with a horizontal scrollbar. Do you want a new issue for that?

Thanks for the confirmation - I saw the same thing with the Build page and fixed that also: https://github.com/dotnet/roslyn-project-system/pull/1808.

@davkean Sure I can try to verify it tonight...what's the process behind getting that specific PR built?

@adammodlin:

Git clone https://github.com/davkean/roslyn-project-system.git
git checkout origin/DebugScaling
Open VS Command Prompt
Run Build.cmd
devenv /RootSuffix RoslynDev

This will start a new instance of VS with the changes (won't affect your main instance).

Thanks all, we've confirmed that we've fixed this for all DPIs.

This fixed via https://github.com/dotnet/roslyn-project-system/pull/1803

authors: adammodlin davkean flcdrg kroehne srivatsn tomeo

repo: dotnet/roslyn-project-system


text:
VB portable template shows in root

fixed with internal PR

authors: davkean jmarolf


text:
Integrate SBRP changes in pre-arcade into main

Active development work has been done in the pre-arcade branch of source-build-reference-packages, but much of it has not been ported to main.  These should be compared and main should be updated.

Should be addressed as part of https://github.com/dotnet/source-build/issues/2316

Resolved with the following pull requests:

https://github.com/dotnet/source-build-reference-packages/pull/222
https://github.com/dotnet/source-build-reference-packages/pull/223
https://github.com/dotnet/source-build-reference-packages/pull/224
https://github.com/dotnet/source-build-reference-packages/pull/225
https://github.com/dotnet/source-build-reference-packages/pull/226

repo: dotnet/source-build


text:
Add Missing API:  "System.Web.Hosting.HostingEnvironment.SiteName" and "System.Web.Hosting.HostingEnvironment.ApplicationID"

Summary
We use System.Web.Hosting.HostingEnvironment.SiteName and System.Web.Hosting.HostingEnvironment.ApplicationID in SharePoint as key to search the target data object. But there is no implementation in adapters. I find that there are alternatives like IHostingEnvironment.ApplicationName, IWebHostEnvironment. But I don't know if it is an equal alternative (we use it as search key so it should be same)
Motivation and goals
Add missing API  System.Web.Hosting.HostingEnvironment.SiteName and System.Web.Hosting.HostingEnvironment.ApplicationID to adapter
Usage
Use SiteName to search
retval =null;
string sitename= System.Web.Hosting.HostingEnvironment.SiteName;
foreach (var service in _services)
{
    foreach (var app in service.Applications)
    {
        foreach (var setting in app.settings)
        {
            if (setting.sitename== sitename)
            {
                retval = app;
                break;
            }
        }
        if (retval != null)
            break;
    }
}

Use ApplicationID to search
string appIdStr= System.Web.Hosting.HostingEnvironment.ApplicationID;
 if (appIdStr!= null && appIdStr.StartsWith("pattern/", StringComparison.Ordinal))
{
         appIdStr= appIdStr.Substring(8, idlen);
         appId = Int32.Parse(appIdStr, NumberFormatInfo.InvariantInfo);
}
return appId;

These values are probably coming from IIS somewhere. Can you identify if they are? If you were to set IHostingEvironment data to those values, would that be sufficient?
If you need the System.Web.Hosting.HostingEnvironment APIs, they'd follow the pattern we did for HttpRuntime that internally it's an interface and exposes the static properties as System.Web did.

This seems like a subset of https://github.com/dotnet/systemweb-adapters/issues/368. Closing this as a dupe for now.

authors: Clounea joperezr twsouthwick

repo: dotnet/systemweb-adapters


text:
Update to Toolkit v3.8

This PR adds the latest code available under the MS-PL license to the master branch.

are you sure 3.8 was still mspl?

I'm pretty sure. The developer is backing this in this issue: https://github.com/xceedsoftware/wpftoolkit/issues/1655

Can I do anything to get this merged and trigger new release?

1.) The Pull request need to build on appveyor, at the moment it does not.
2.) The Release is always build from the extened branch. The Extended Branch contains many fixes, so the master needs to be merged to extended

@FroggieFrog, @jogibear9988 Is there any chance you still plan to work on it and merge it?
I would love to use it in my project but I need fixes that are made in version 3.8.
Thanks

@FroggieFrog, @jogibear9988 Is there any chance you still plan to work on it and merge it? I would love to use it in my project but I need fixes that are made in version 3.8. Thanks

I do not plan to work on it.
if you work on it, I could merge when it compiles

@jogibear9988 you can find it here :) #41

authors: FroggieFrog Houzvicka jogibear9988

repo: dotnetprojects/WpfExtendedToolkit

license: MS-PL


text:
🛑 Biseri-jadrana.si is down

In 04b2f7c, Biseri-jadrana.si (https://www.biseri-jadrana.si/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biseri-jadrana.si is back up in da06589.

repo: dotsi/bitamiuptime


text:
🛑 Spica.com is down

In 52a381a, Spica.com (https://www.spica.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Spica.com is back up in e052ff3 after 43 minutes.


text:
🛑 Biseri-jadrana.si is down

In e80916e, Biseri-jadrana.si (https://www.biseri-jadrana.si/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biseri-jadrana.si is back up in f4a095c after 4 minutes.


text:
🛑 Biseri-jadrana.si is down

In c774ec1, Biseri-jadrana.si (https://www.biseri-jadrana.si/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biseri-jadrana.si is back up in 910395a after 3 minutes.


text:
🛑 Biseri-jadrana.si is down

In 7dad5af, Biseri-jadrana.si (https://www.biseri-jadrana.si/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biseri-jadrana.si is back up in ea0015b.


text:
🛑 Biseri-jadrana.si is down

In 748d66f, Biseri-jadrana.si (https://www.biseri-jadrana.si/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biseri-jadrana.si is back up in fba0261.


text:
Update package.xml

hi i have updated the package with missing test classes.

@douglascayers Hey Doug, would you mind accepting this PR?  I have a colleage that would like to use this tool.

authors: badrianth dancinllama


text:
Update Delicate Synthesis icons

Add in delicate synthesis icons for various crafts

Are you still trying to find some of the icons?

Are you still trying to find some of the icons?

Not so much trying to find them as need to level crafters to point that icon becomes visible and can be pulled from game :)
As crafters hit 76 I can do the delicateSynthesis and as they hit 78 I can get the intensiveSynthesis. A work in progress :)

Ok that's added the last of the missing Delicate Synthesis icons.
I've also included the revised level 80 formula which is almost spot on for quality and progress, compared with the current pre-80 formula which is wildly out when you hit 80. This would be a big improvement for beta site to enable more users to test further.

Deployed to beta site.

authors: ShammyLevva doxxx

repo: doxxx/ffxiv-craft-opt-web

license: Zlib