text:
Repo maintained anymore?

Just wanted to see if the authors of this repo are maintaining it anymore, or if its been left for the larger community.

i have always felt this way.  there is little to no movement on this repo except to update dependencies

i am actively using this project, i may create another repo and so it can be maintained properly

Hi All, I am no longer part of Microsoft and due to my current employment can no longer contribute to this project. I did contact forks at Microsoft but haven't heard back anything. If anyone plans to fork and maintain it, I can help with any knowledge required.

i am actively using this project, i may create another repo and so it can be maintained properly
If you fork it, I'll contribute.  I'd like to keep this project going, there are not many open source rules engine projects for dotnet out there!

i created a fork and i have been actively making changes since.  mostly today

Just made the first release in my fork. Updated dependencies and updated to c# 12.0

Neat.  I have solved ALL issues in my fork.  I will be supporting new features and issues in mine.

@asulwer First off all great work! it seems you are determined to take it forward. Just a couple of advice:

RulesEngine traditionally has been conservative towards making breaking changes, if we do, we give people some grace period to move to new implementation.
Since your fork fixes couple of issues and adds new features(and potentially breaking changes), it would be great to add a migration guide(in case u release to nuget) . Users might eventually move to the fork but that would require a little hand holding.
Also you might want to look into the .github folder. It has CI pipelines for PR check. and along its history it had full release pipeline (which was later removed and moved to azure pipelines). It can help setup the release process

@abbasc52
Thank you for the template to the workflow. Just integrated  an updated version of it.

Hey guys, we are using this nugget in one of our core applications… thats essencial we keep maintaining it, count on me on it.
Lets talk to see the future plans for it
Thanks for the great job so far 😄

@abbasc52 we weren't sure if you were still active.  your linkedin profile states you are no longer with Microsoft.  we assumed this meant this wasn't going anywhere.  if you want to sit back and take a break thats fine, would you be willing to let a contributor move this forward? or maybe separate from Microsoft?  my planned direction will continue to make large breaking changes.  my fork wasn't to push you out, please do not think that.  issues are being resolved but not closed, just doing what i can.

@asulwer On the contrary, I want some to take it forward. I believe it is a great project and dont want it to die like this. I have been trying to get someone at Microsoft to take it forward but did not get much confirmation on it.
My comments earlier were just meant to ensure people looking for a maintained folk have a easy way out. If you have a different goal in mind, that is fine too :)
@RenanCarlosPereira , @timophe-91 , @RenanCarlosPereira  and @asulwer maybe you guys can come together and come up with a plan and a single fork? together it should be easier but you would need to agree on where this project should head
I know it is asking too much out of you folks given I cant contribute anything anymore. Just a selfish wish to make sure this library remains useful to others :smile:

I would love to work together on this. But my issue is i don't want breaking changes so early and more in the long run with backwards  compatibility if possible. Since i'm using this in working environment and know it could be a pain in the ass to explain to any higher ups to migrate such stuff.
And since there are so few RulesEngine for .net it maybe could help too to split and it must not be a bad thing.

I'd love to collaborate on this project, but my main concern is avoiding frequent breaking changes, especially early on. Maintaining backward compatibility in the long run is crucial. Since I'm using this in a working environment, it would be difficult to justify (frequent) migrations to higher-ups. Given the limited number of Rules Engines available for .NET, it might be beneficial to explore splitting the project, as this doesn't necessarily have to be a negative outcome.

@asulwer we can do it.
I don't want any breaking changes any soon as we are using it in some big projects.
I just have only one big concern thats come from this bug 🥺
https://github.com/zzzprojects/System.Linq.Dynamic.Core/issues/821
Lets keep this going with minimal breaking changes as possible.
If you guys want we can set up a quick meeting to talk about forks and other stuffs

@RenanCarlosPereira if RulesEngine is affected please move this to an issue.

Yeah it’s affecting it, I will open a bug, with an example of unit test on how its affecting it, thanks

change is inevitable.  at the request of users, breaking changes occur in my fork but...current incorrectly created methods have been marked obsolete to support old code.  i am moving in a new direction with my fork, so is it a fork? for now yes but in the future no.

@RenanCarlosPereira if RulesEngine is affected please move this to an issue.

opened a new bug for this:
https://github.com/microsoft/RulesEngine/issues/614

@abbasc52 is there a continuation plan for this project? if you are not working for this project, how are we able to move forward but still making sure that we maintain the correct practice of PR's, code reviews and checks? And who might be the best candidates as the gate keepers of this codebase?

@jerbersoft did you take a look at my fork?  all of the listed issues have been resolved there.  i wasn't opening PR's as i should but that has changed

@jerbersoft there are different forks now.

We will try to maintain it in the @asulwer branch
We are going to keep minimal breaking changes.
Please feel free to join as a contributor
Only PRs are allowed, we have 2 breaking changes, not planning to introduce any other breaking changes (not for now)
If we do we will ask the comunity and discuss it together before any release or major changes

@timophe-91, I have reviewed the code changes from 6.0.0 to 6.0.3 and its safe to make the move
Please be aware about those 2 breaking changes in the 6.0.0, other than that all the behavior remains the same.

@RenanCarlosPereira I've got my reasons to not trust that fork. But here is not the place to talk about those things. :) As said in another place, i stay with my own fork. :)

No problem @timophe-91
I got it, anyway, I will try to keep everything in order there, in case you change your mind.
Cheers 🍻

I just found out this is unmaintained and opened https://github.com/microsoft/RulesEngine/issues/625 to mark it as such.
However, what is the active/best fork now? I found the following:

https://github.com/timophe-91/RulesEngine
* https://github.com/asulwer/RulesEngine

Could not you work together to have one active fork?

Hi @rklec,
Thanks for bringing this up. I’m co-maintaining the RulesEngine fork along with @asulwer. This fork is quite active, and we’re committed to addressing issues and updating it regularly. Feel free to contact us anytime — we’re here to help and will do our best to resolve any concerns as quickly as possible.
As for @timophe-91, he’s maintaining his fork independently.
While I’m not entirely sure of his specific reasons, I’m sure he has his motivations for doing so.
For my part, I’m fully invested in the @asulwer fork, which I’m also using in projects for several large companies globally. This is the version I recommend for ongoing development and support.
Best regards,

I just found out this is unmaintained and opened #625 to mark it as such.
However, what is the active/best fork now? I found the following:

https://github.com/timophe-91/RulesEngine
https://github.com/asulwer/RulesEngine

Could not you work together to have one active fork?

I'm not working in the fork of asulwer. As mentioned before i have my reasons to to not do that.

Sorry everyone! Please let me know any pull request needs to be merged

authors: BSmith-APFM RenanCarlosPereira YogeshPraj abbasc52 asulwer jerbersoft rklec timophe-91

repo: microsoft/RulesEngine


text:
Level 1 with non Domain Joined Devices

Hi,
I have around 15 windows 10 machine and they are nondomain joined, they are used for the daily working process and accessing cloud data, mainly the used programs are web browsers and office applications with some default windows applications.
I went over the Level 1 security recommendation pointed here: _https://github.com/microsoft/SecCon-Framework/blob/master/level-1-enterprise-basic-security.md_  and thinking to skip the security recommendations that have the Domain member as my devices are not domain-joined.
is that a correct approach to implement the previously mentioned recommendation ! to skip Domain member controles on the non-domain devices?
Thanks in advance.

Yes - if a configuration is not relevant, you can feel free to just leave it out of what you apply. Out of curiosity, how are you applying policies?

It would be great if we could include guidance and recommendations to the security baselines for non-domain joined i.e. modern workplaces. We have noticed that when configuring devices with Intune, not all the configuration settings referenced in the security configuration baselines are available natively in the UI, some can be configured using OMA URI settings or by using scripting, but the question really is, do we actually need to configure settings on a modern workplace that are usually only needed for domain joined devices. A good example is audit logging, unless I deploy some sort of cloud based log collector solution such as the MMA agent on my windows client devices, or IT security would still wish to have local security logs enabled, I feel that there is no requirement to add such configuration to a AzureAD registered device. What are your thoughts on this?

source: gharchive/issue

authors: alexverboon appcompatguy muradmomani

repo: microsoft/SecCon-Framework

license_type: permissive

license_source: github-api


text:
Help determining LargeFileTransfers port

Hello.  I came across an "issue" while trying out this project today and just wanted to share the solution.  In case it helps someone else down the road.
After getting the SimpleRemoteConsole running on a remote machine, I am to use the RpcClient.Upload() procedure to push files to the remote machine.  This was working great, except that for each upload attempt, the console would output that it was listening to a completely different port: 50118, 50121, 50122, 50124, etc.  This works fine if you disable the firewall.  In case I do not want to disable the firewall, I would still need to open several hundred ports in order to upload over an extended period of time.
Solution: Notice the "Upload" procedure accepts an optional "portNumber" argument.  Passing in a port number other than "0" will force the SimpleRemoteConsole to listen on that port.

Solved.  See OP.

Hi there - just wanted to let you know we added a note in the tutorial about this. Thank you so much for the suggestion.

authors: Jack-Edwards iUnknwn

repo: microsoft/SimpleRemote

license: MIT


text:
GPU memory leakage (CUDA out of memory after 2 epochs)

Hi,
Thank you for this repo.
Unfortunately, I am unable to train this repo for more than ~2 epochs, at the end I keep getting CUDA out of memory.
Tracking the GPU memory consumption a slow and steady increase is visible.
To check it, I have decreased the BATCH_SIZE to 6 while running on 3 RTX-2080 (10.7 g) GPUs, using nvidia docker cuda:10.1-cudnn8-devel-ubuntu18.04 and pytorch 1.8 (cuda 10.1).
Running code:
python train.py --gpu 0,1,2 --workdir /temp_out --model sparenet

Have you encountered such a problem? Is some variable history not released?

I might have spotted the problem, not sure as I have only briefly examined the code, but it seems that the actual losses (not the value or a detached version) are accumulating for visualization, will report here if this is the problem.

It seems that I was right, and I would be happy to get an approval here.
All the update operations should take items not Variables.

@orenkatzir
It makes full sense to me. Thanks for reporting the issue! We will fix it.

authors: AlphaPav orenkatzir

repo: microsoft/SpareNet


text:
Remove duplicate example

It is exactly identical to the two lines immediately below it.
I am not clear on the meaning of "string string params" in this case.  I have left that as-is because I do not understand it.

Updated, thanks

source: gharchive/pull-request

authors: altearius orta

repo: microsoft/TypeScript-Website


text:
Tradução do arquivo jsx.md

Minha primeira Pull Request no github 👍
@khaosdoctor, @alvarocamillont, @danilofuchs e @orta

Obrigado pelas correções, pessoal! :)
Irei melhorar nas próximas.

Looking good to me!

authors: GabTheOne orta


text:
Validate the PR deploy process

Pairs with #933

Gonna do this for a fork to make sure


text:
warn about conflicts at renaming

Search Terms
https://github.com/Microsoft/TypeScript/issues?utf8=✓&q=is%3Aissue+rename+conflict
Suggestion
renaming doesn't account for possible conflict which can be either good or bad, but in any case it should be a conscious decision of a developer, so please in case of conflicts shoot out a warning

Doesn't seem like anyone noticed

repo: microsoft/TypeScript


text:
React ref union types cause false errors

Search Terms
react ref union type
Suggestion
Currently React refs do not work when you applying it to different elements depending on some condition. I'd like to not have Typescript errors for this case
Use Cases
Sometimes we need to conditionally render different elements and attach refs to them:
function Button({ href }: { href: string }) {
    const ref = React.useRef<HTMLAnchorElement | HTMLButtonElement>()
    if (href) {
        return
//               Type 'RefObject<HTMLAnchorElement | HTMLButtonElement>' is not assignable
//               to type 'RefObject<HTMLAnchorElement>'.
    }
    return <button ref={ref}></button>

}

This code is valid Javascript, but reports an error in Typescript.
Playground example
I think, this is also related to the general covariance issue: https://github.com/microsoft/TypeScript/issues/10717#issuecomment-461977080
But I am wondering if there could be a more simple solution to this particular case

https://github.com/Microsoft/TypeScript/issues/21759 could solve this, as when passing a ref object to React.createElement, only the write side is consumed.

Solved my issue via React.useImperativeHandle hook:
function Button({ href }: { href: string }, ref: React.Ref<{focus(): void}>) {
    const ref = React.useRef<any>()
    React.useImperativeHandle(ref, () => ({focus: () => ref.current && ref.current.focus}))
    if (href) {
        return
    }
    return <button ref={ref}></button>

}


text:
import 'constants'  always resolving to the node 'constants' module

VSCode Version:

Version: 1.44.2
Commit: ff915844119ce9485abfe8aa9076ec76b5300ddd
Date: 2020-04-16T17:07:18.473Z (2 wks ago)
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.3.0

OS Version: macOS Catalina 10.15.3 (19D76)

Steps to Reproduce:

Open VSCode.
Create a file src/constants.js exporting foo
Import foo as import { foo } from 'constants'
Hover over the constants file path.
See the following.

module "constants"
@deprecated — since v6.3.0 - use constants property exposed by the relevant module instead.

⌘ + click on constants file path.
See there are 2 definitions – constants.d.ts and index.d.ts but no src/constants.js

Expected result:

see the definition of foo from src/constants

The same issue occurs when using foo for the first time in a module, no import suggestion is shown.
My jsconfig.json file
{
  "compilerOptions": {
    "baseUrl": "./src",
    "jsx": "preserve",
    "module": "es6",
    "moduleResolution": "node",
    "target": "es6"
  },
  "exclude": [
    "**/node_modules/*",
    "coverage",
    "dist",
    "node_modules"
  ],
  "typeAcquisition": {
    "include": [
      "cypress",
      "jest"
    ]
  }
}

Does this issue occur when all extensions are disabled?: Yes/No

I believe this is the expected behavior if you have the node typings installed, but someone on TS would have to confirm that. Note that if run the script in node,  require('constants') also always resolves to the node constants module and not the local constant.js file.
I do see the expected local constants.js file being resolved if I use a relative import: './constants"

This is the intended behavior

Hey @RyanCavanaugh, that sounds good! How would I go about overriding it to resolve to my local “constants” when working on client code? Importing from “constants/index” doesn’t look as nice 😀 do you recommend simply renaming the folder to something else to avoid all this trouble?

You can add a path mapping

You can add a path mapping

How exactly you should specify it? Something like "constants": ["constants/index"] doesn't work for me.

I've made a reproduction of this issue here: https://codesandbox.io/s/priceless-mccarthy-9uk9p?file=/tsconfig.json
Notice in App.js that I can easily import and get the correct type from modules from 'test.ts'; however, with 'constants.ts' that is not the case despite manually creating a path for it.

authors: RyanCavanaugh kylemh mjbvz mmakarin mrlubos


text:
Idea: Can declaration emit synthesize type aliases?

Object types can be very large and in (e.g.) a react project that makes heavy use of type inference, it's not uncommon to have to refer to a type that is either not imported or is simply anonymous (e.g. a props type).  When these appear in multiple places in a declaration file, they tend to expand it considerably.  Perhaps we could just synthesize type aliases for them?

We'd have to be careful not to change the exported API shape
We could use a heuristic to skip the work for small types (e.g. < 20 characters)
Even if we didn't wait until the second use of a type to decide to extract it, we'd be adding ~4 tokens per type (type id = and id at the use site)

https://github.com/microsoft/TypeScript/pull/30979 is along the lines of what I think we'd prefer to see

@weswigham What's the scope of those inline type aliases?  Being able to use them across multiple declarations seems key to reducing declaration file size.

In that case, within a given type node, so you can serialize a recursive or self-referential type. (Which today usually expand till they hit a depth limiter)

Reviving this idea.
I am discovering we're having similar issues specifically with the io-ts library (similar to zod which I believe has the same issues) where the type derived from the codec expands everywhere its referenced instead of using a simpler named type. Some of our emitted definition files are tens of MB with repetitive type expansion. Using explicit types reduces the files back to expected sizes but defeats the purpose of being able to infer the types.

authors: amcasey jleider weswigham


text:
Document type of HTML elements in .html files

Suggestion

🔍 Search Terms

dom html types
✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

📃 Motivating Example

I want to make a custom JSX transformer that just returns strings.
I want to export the types the JSX module needs.
I want to map over the attribute types you see in .html files.
But I can't find these things.
They are mysterious and hidden from me.
Can you document them?
And export them if needed?
💻 Use Cases

See above.

More details:
I have created these types:
export type IntrinsicElements = {
  [Tag in keyof HTMLElementTagNameMap]: (
    { [Attr in keyof Omit<HTMLElementTagNameMap[Tag], 'children' | 'toString'>]?: string }
    & { children?: any, class?: string }
  );
};

export type Element = string;

However, this is not exactly the same type as what .html files offer. There are two obvious differences:

className is offered instead of class so I have to manually add this in here
style is a Style object instead of a string; which also means I don't get VS Code's super great auto-completion inside the style-string

It seems everyone is confused, because how would you actually use it?

class is a reserved word in JS, so everywhere you refer to it in JS, it's className. It's the same for JSX and the native Element.className.
How would you get auto-complete if you are in a string anyways?

@Josh-Cena (a) it's just a key in attrs; (b) VS Code already does this in HTML mode

What VS Code does in HTML files has nothing to do with TypeScript.  The types you seem to be looking for aren't hidden from you; they just don't exist.

You would really need to make some kind of codegen tool to make this work ergonomically.
For CSS string completions, I would recommend using a VS Code or TypeScript language service plugin. We're not in a position to be providing that kind of data.

Thanks @RyanCavanaugh. This is one of the few missing things that would make the new TypeScript web framework Novo Cantico better, since right now it has nothing close to VS Code's .html convenient support for HTML attributes. My plan based on your advice is to somehow pre-generate a .d.ts file to include into the framework itself.

authors: Josh-Cena RyanCavanaugh fatcerberus sdegutis


text:
Allow destructured object entries with default parameters not to be optional

Suggestion
🔍 Search Terms
default value optional object destructure
✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
If a default value is set on a required field in an object, I wish Typescript allowed an undefined value to be passed in without throwing an error.
I don't think this would be a breaking change because it will only affect situations that are currently errors.
I feel like there's probably something fundamentally weird about the way I'm thinking about it, but I wanted to at least create an issue so that other people could find it, as I wasn't able to find anything on this.
📃 Motivating Example
const {a = 1, b}: {a: number; b: number} = {b: 1};

This throws an error, but I believe that this is readable, and as far as I understand it Javascript could never allow the value of a to be undefined in such cases.
💻 Use Cases
The primary use case is for React prop interfaces:
interface Props {
  a: number;
  b: number;
}

const Component: React.FC<Props> = ({a = 1, b}) => {
  return <>{a + b}</>;
};

<Component b={1} />;

This shows an error unless a is made optional, but it doesn't seem like there's anything wrong or confusing about this to me.

Previously discussed at #30488.
By design, type annotations are always the last word on anything. This is important for predictability and for performance.

For those unable to follow, like me without a lot of head-scratching:
@RyanCavanaugh seems to be saying that the following two lines should both throw the same error:
const {a = 1}: {a: number} = {a: undefined};
const {a = 1}: {a: number} = {};

I respectfully disagree, I don't think either of them should throw an error, since it is promised that a will be a number and so that is what we get. My way of thinking about it seems quite reasonable unless we're allowed to put type hints in the destructuring syntax. Then there would be a way to distinguish between these cases, though I still don't understand why one would mind (maybe a case where you reuse the assignment operator in a statement to chain it in a weird way?):
const {a = 1}: {a: number} = {}; // error cause we're expecting an object that contains a as a number, which {} is not
const {a: number = 1} = {}; // fine cause we're implicitly expecting any object, and we know that a is guaranteed to be a number

Personally I'd want to see a case where it's ambiguous what the author intended and the transpilation is more complicated than just stripping out everything after the colon, which is generally what I think of as the defining feature of typescript. I don't know about performance but it seems unlikely that you need a whole bunch of overhead just to remember whether the destructuring had a default parameter or not when you check if an undefined value was passed in.

Personally I'd want to see a case where it's ambiguous what the author intended

I think the intent of this line is extremely clear:
const {a = 1}: {a: number} = {};

I want to initialize a binding with an object
The value that must initialize the binding is { a: number }
If not, I have made a mistake and should see an error
After that, if the value for a is undefined, set it to 1

Step 3 is unambiguous and what happens at step 4 is immaterial. Further proof of this intent is counterfactual: had I wanted a to be optional, I could have written { a?: number } instead, but I didn't.

I think the disconnect is that as a maintainer, you see the behavior of a type annotation as saying something about what objects can enter the zone it's responsible for, but as a user, I am thinking of its purpose as giving me guarantees about the code that follows. So to me as long as there's no earthly way for me to interfere in the middle of an expression, I want the annotation to tell me what types the expression gives me, not what I can pass into it.

const {a = 1}: {a: number} = {};

self-evidently and unambiguously (:p) says that we are destructuring an object and that what we'll have after is a number called "a", which is true

It depends on what you think destructuring is a sugar for. If you wrote
const obj: {a: number} = {};
const a = obj.a === undefined ? 1 : obj.a;

then the type error is still there.
TS is consistent about this view of what destructuring means:
const {a = 1}: Partial<{a: number}> = {};
a // correctly number, not number | undefined

Obviously there are multiple ways to interpret the situation, but both have trade-offs and your view of this being an incompleteness is someone else's view of a possible lack of error here being an unsoundness.

Yeah that's what I'm trying to get at, you said this was "discussed" but in both cases it was just a post by you that's basically impenetrable to users. I understand the need for maintainers to have a consistent philosophy, I just think it's helpful to have it written out what the disagreement is because users rarely have to think of it that way.

I'm not sure what you want me to do?

I wanted you to make that comment that explains it! Thank you, unironically!

Happy to help 😅

authors: RyanCavanaugh skondrashov


text:
Support string literals as spread argument

Suggestion
A tuple of characters can be concisely represented as a string literal – for example "0123456789" is a convenient representation of ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"] for many purposes. However when using the spread operator ... on a string literal, e.g. in a function call, TS2556 is raised with the message: "A spread argument must either have a tuple type or be passed to a rest parameter".
My suggestion is therefor to allow string literals to be treated like string tuples in conjunction with the spread operator.
🔍 Search Terms
string literal, spread operator, spread string literal, spread characters, string as tuple
✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
When using the spread operator on a string literal it should work the same way as when it's used on a string tuple. E.g. the following expressions are equivalent in plain JS and thus should be supported the same way in TS:
fn("a", "b", "c")  // OK
fn(...["a", "b", "c"] as const)  // OK but impractical
fn(..."abc")  // Fails but should be OK

📃 Motivating Example
I'm using ts-pattern to match keyboard events. For this example let's say I want to use it to control volume:
const handleKeyDown = (evt: KeyboardEvent) =>
  match(evt.key)
      .with("+", () => updateVolume(vol => vol + 0.1))
      .with("-", () => updateVolume(vol => vol - 0.1))
      .with(..."0123456789", digit => updateVolume(0.1 * digit))
      .otherwise(noOp)

For the +/- keys, this would increment/decrement the volume by 10%. When pressing a number key it should set the volume directly to the corresponding multiple of 10%.
Note that ts-pattern's .with method takes any number of arguments for pattern matching and if any of the arguments matches the input calls the final argument as a function. Of the example above the fifth line does not work with current TS (4.8.4). I've tried the following variations, all of which fail type checking:
      .with(..."0123456789", digit => updateVolume(0.1 * digit))
      .with(...("0123456789" as const), digit => updateVolume(0.1 * digit))
      .with(...([..."0123456789"] as const), digit => updateVolume(0.1 * digit))
      .with(...(Array.from("0123456789" as const)), digit => updateVolume(0.1 * digit))

However the following work:
      .with("0", "1", "2", "3", "4", "5", "6", "7", "8", "9", digit => updateVolume(0.1 * digit))
      .with(...["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"] as const, digit => updateVolume(0.1 * digit))

You might call this a matter of convenience but I would argue that it improves readability in those cases where it comes in handy – and code readability could always be argued to be "just" a convenience.
💻 Use Cases
Whenever you want to hard code a tuple of characters it is easy to either use a string literal directly or spread it into an array, such as
const alphabet = [..."abcdefghijklmnopqrstuvwyz"] as const

This is quite universal and can be useful whenever you need a hard coded tuple of characters. Some examples:

all digits, all latin letters, etc. (seen above)

when handling user input
building a parser of some sort

all characters valid in a password
"wasd" (video game keyboard controls)
Characters are sometimes used like flags (e.g. as the second argument to the RegExp constructor).
Many educational examples/exercises revolve around string manipulation (e.g. on codewars.com).

This is intentional. Duplicate of https://github.com/microsoft/TypeScript/issues/39292#issuecomment-650586962.

String spread is fine for ASCII stuff, but quickly goes off the rails for more complex characters. e.g. [..."🤷♂👴🏻"] is ['🤷', '', '♂', '', '👴', '🏻'], [...", ֶ, ִ, ֹ"] turns into [',', ' ', 'ֶ', ',', ' ', 'ִ', ',', ' ', 'ֹ'].

Well, that's a shame. Calling this feature "very rare" seems rather subjective, if not speculative.
I was under the impression that TS tries to add type safety to JS, not remove features that might backfire when used carelessly. With that reasoning you might as well forbid half of JS's standard library.
@RyanCavanaugh Emojis and other weird utf characters are always trouble when manipulating strings, this is not exclusive to spread syntax. You can shoot yourself in the same foot with pretty much any String method, or any other use case where strings are treated as Iterables (which TS does support!). And putting invisible whitespace in a string literal is pretty much exclusively useful for trolling coworkers…

Every type error we issue is a subjective call of what is and isn't a good idea in JS. There's no bright line anywhere.

I was under the impression that TS tries to add type safety to JS, not remove features that might backfire when used carelessly.

Except that’s exactly what TS does, almost by definition.  There is no undefined behavior in JS.  See, e.g. https://github.com/microsoft/TypeScript/issues/38471

@fatcerberus parseInt is basically runtime type casting, so naturally it's prone to some special treatment when it comes to static type checking. In fact, parseInt is exceptionally treacherous and deserves exceptional treatment – but IMHO that should still remain an exception. Using it as a precedent for removing features with pitfalls is an insidious argument, as it can be applied to virtually any feature.
Plus you can still (ab)use parseInt by adding a type assertion, so you can still access that functionality if you really want to. String literal spreading on the other hand is just basic syntax sugar for a feature that TS already otherwise supports (iterating strings). But in its current state there is no practical way of forcing the compiler to accept it.
Anyway, I'm going to stop trying to argue my point here. I'm a bit disappointed with the offhanded dismissal of my proposal – it does not feel like there was any real attempt at objective consideration. Though of course I don't know all of TS's history and it is very possible that I'm biased.

Using it as a precedent for removing features with pitfalls is an insidious argument, as it can be applied to virtually any feature.

The relevant question is "if this feature is allowed by the type system, will it always do what most people expect it to?"  In the case of parseInt(numVal), people tend to read this as "get the integer part of numVal"--which of course it doesn't do if the number is too large--it returns garbage instead--hence making it dangerous.  In the case of [ ...stringVal ], most people IMO will read this as "split stringVal into characters" (indeed, your exact use case) - which works for ASCII strings but breaks down for Unicode in general, because it actually means "split into UTF-16 codepoints".  This difference in behavior is likely to be surprising, and, from TS's point of view, dangerous.  This is all completely subjective, of course, but the entire type system has been built on these kinds of subjective judgment calls, for better or worse.
At any rate, you can still cast the string literal (..."abc" as any as string[]).

But in its current state there is no practical way of forcing the compiler to accept it.

Everything above having been said, what you're trying to do does, in fact, appear to work already:
function fn(...args: string[]) { console.log(args); }
fn(..."abc");  // no error - prints a, b, c
const alphabet = [ ..."abcdefghijklmnopqrstuvwxyz" ];  // also no error
console.log(alphabet);  // prints alphabet split by character

TypeScript Playground link

Anyway, I'm going to stop trying to argue my point here. I'm a bit disappointed with the offhanded dismissal of my proposal – it does not feel like there was any real attempt at objective consideration.

We obviously put a lot of consideration into how this feature works when implementing it; re-enacting that design conversation with every user who disagrees is not scalable. We told you why the feature works the way it does, and that it was on purpose. You're welcome to offer a rebuttal and try to change our minds, but this is fundamentally a bug tracker, and if you phrase something like it's a bug when it's not, it's getting triaged as such.

authors: MartinJohns RyanCavanaugh fatcerberus philer


text:
JSDoc comment inheritance of class property types

Suggestion

🔍 Search Terms

VSCode IntelliSense autocomplete property hover documentation inheritance propagation from class object property member type annotation JSDoc comment
✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I believe it's extremely helpful for productivity when developers don't have to leave their IDE for documentation and could just hover something and see everything about it through the power of TypeScript and JSDoc.
The problem is that class members and function parameters may refer to the same thing, but don't use the same JSDoc annotations. This leads to either library authors having to copy-paste the comments, or users not being able to see them in some circumstances.
📃 Motivating Example

Let's say I have class Test with a documented property foo:
class Test {
  /**
   * It does foo things!
   */
  public foo: string;
}

let test = new Test()

test.foo

I can hover test.foo and see what it does:

However, foo must gets its value from somewhere, so suppose I have an options object in the constructor where that value is provided:
class Test {
  /**
   * It does foo things!
   */
  public foo: string;

  constructor(options: {
    foo: Test['foo']
  }) {
    this.foo = options.foo
  }
}

let test = new Test({
  foo: 'hello'
})

Sadly, hovering foo: 'hello' doesn't display the comment:

My expectation is that when I specify that something is of type Test['foo'], it should inherit the comments associated with it. The only exception should be when I explicitly provide a separate comment:
constructor(options: {
  /**
   * This takes precedence.
   */
  foo: Test['foo']
})

💻 Use Cases

I want to use this for documenting my code for other people.
Currently, to achieve what I want, I need to copy-paste the comment in both places:
class Test {
  /**
   * It does foo things!
   */
  public foo: string;

  constructor(options: {
    /**
     * It does foo things!
     */
    foo: Test['foo']
  }) {
    this.foo = options.foo
  }
}

This is bad for maintenance and if you have a few more properties to document, it could hurt readability as well.
Maybe a downside of what I'm proposing is that I'd be forced to use Test['foo'] as my type, if I wanted the comment to appear. This would make the constructor popup confusing:

So perhaps the best solution is somewhere in the middle - have a special JSDoc annotation, e.g. @show, that allows you to "attach" a comment from an existing type:
class Test {
  /**
   * It does foo things!
   */
  public foo: string;

  constructor(options: {
    /** @show {Test['foo']} */
    foo: string
  }) {
    this.foo = options.foo
  }
}

This way, whenever I want the comment to appear, I just add /** @show {Test['foo']} */ above whatever I want to document. I can greatly improve the developer experience of everyone who uses this code, while not being forced to alter my type annotations.
Here's a playground link to see the issue in action.

why not
constructor(options: Pick<Test, 'foo'>) { /* ... */ }

the documentation is attached to the property, not the type, so to me the behavior kind of makes sense. If you make your options property something that is pulled directly off the source, rather than a new property with no documentation whose type is copied from somewhere else, the documentation is pulled from the source too.

Hm, I didn't know that Pick worked like that. It appears to do exactly what I want. Here's a playground link for anyone else wondering.
If you want to copy the type of a property, along with the documentation, use Pick. ✔

authors: andrewbranch hdodov


text:
Regression in autocompletion on spread generic arguments

Bug Report

🔎 Search Terms
autocomplete, regression
🕗 Version & Regression Information

This changed between versions 5.0.4 and 5.1.3

⏯ Playground Link
Playground link with relevant code
💻 Code
function fn<T extends ('value1' | 'value2' | 'value3')[]>(...values: T): T { return values; }

const value1 = fn('');
const value2 = fn('value1', '');

🙁 Actual behavior
It should autocomplete inside both '' (empty string) places with value1|value2|value3 possible values, however it shows incorrect (kind of randomly gathered) options. For eg.:

🙂 Expected behavior
It should show only value1 / value2 / value3 options (as it does correctly with 5.0.4 and before), like this:

This issue could be related to (https://github.com/microsoft/TypeScript/issues/53555) and (https://github.com/microsoft/TypeScript/issues/52726) but I think my case is more basic, and appeared only in the latest (5.1.3) version of TS. (couldn't test if versions between 5.1.0 and 5.1.3 were affected or not, I could test only 5.1.3).

Bisected this to: https://github.com/microsoft/TypeScript/pull/52717 . Gonna look into fixing this soon


text:
Typescript error: Argument of type 'registerResponseBody' is not assignable to parameter of type 'WritableDraft'

🔎 Search Terms
typescript, type error, reactjs, nextjs, redux-toolkit action
🕗 Version & Regression Information
I am using the same version since I started the project. I have used redux-toolkit asyncThunk action for adding the user. I am attaching the initialStates and the used types as well. please help me to fix the issue.
This is my initial states
⏯ Playground Link
No response
💻 Code
interface OrganizationUserState {
    users: AuthenticatedUser[];
    status: 'pending' | 'error' | 'success' | null;
    error: string | null;
}

const initialState: OrganizationUserState = {
    users: [],
    status: null,
    error: null,
};

// Invite a User to an Organization
export const inviteOrganizationUser = createAsyncThunk<registerResponseBody, registerRequestBody>(
    'organizationUserSlice/inviteOrganizationUser',
    async (user, thunkAPI) => {

        try {
            const response = await HttpService.post(`/organization/${user.organization}/invite`, user);
            return await response as registerResponseBody;
        } catch (error) {
            return thunkAPI.rejectWithValue('Error');
        }
    }
);

.addCase(inviteOrganizationUser.pending, (state) => {
                state.status = 'pending';
                state.error = null;
            })
            .addCase(inviteOrganizationUser.fulfilled, (state, action) => {
                state.status = 'success';
                state.users.push(action.payload)
                // state.users = [...state.users, action.payload];
            })
            .addCase(inviteOrganizationUser.rejected, (state, action) => {
                state.status = 'error';
                state.error = action.payload as string;
            })

export type registerResponseBody = Success<AuthenticatedUser> | Fail;

export type Success<T> = {
  success: true;
  payload: T;
};

export type Fail = {
  success: false;
  error: string;
};

🙁 Actual behavior
I am getting a typescript error when I push the new Authenticated user to the existing state.
Argument of type 'registerResponseBody' is not assignable to parameter of type 'WritableDraft'
🙂 Expected behavior
It should add to the existing User state when I push the newly registered user to it.
Additional information about the issue
Can someone check this issue, because the registerResponse type is the same as an Authenticated user, I have added all the type in my code.

If you believe you found a bug in TypeScript, then it's best to provide a self-contained minimal example (that's why the template asks for a playground link). If you're just struggling with the usage of Redux, then this is not the right place to ask.

authors: MartinJohns niralivasoya


text:
tsserver plugin receives old proxy on configuration change

🔎 Search Terms
tsserver plugin old proxy
🕗 Version & Regression Information
Happens on 4.4.3, 5.2.2 and 5.3.0-dev.20230930 at least.
⏯ Playground Link
No response
💻 Code
Using this https://github.com/vemoo/TypeScript-TSServer-Plugin-Template
npm ci
tsc -p .
cd example
npm ci
code .

Open index.ts, ensure you are using typescript from workspace, "Command Palette..." > "TypeScript: Select TypeScript Version..." > "Use Workspace Version".
"Command Palette..." > "TypeScript: Open TS Server log" (enable it if prompted)
Go back to index.ts and trigger completions at any point. Search log file for my-plugin: getCompletionsAtPosition, a line like this will appear:
Info 151  [12:18:49.536] my-plugin: getCompletionsAtPosition ({"init":1,"create":1})

In the example folder in a terminal run touch tsconfig.json, go back to index.ts and trigger completions. Open log and search for my-plugin: getCompletionsAtPosition again. New lines appear:
Info 244  [12:22:23.378] my-plugin: getCompletionsAtPosition ({"init":2,"create":2})
Info 245  [12:22:23.378] my-plugin: getCompletionsAtPosition ({"init":1,"create":1})

🙁 Actual behavior
When tsconfig.json changes, the plugins init and create are called again but the info.languageService passed here https://github.com/vemoo/TypeScript-TSServer-Plugin-Template/blob/7ef3052284f644c9d15a048f43dcffc07c072936/src/index.ts#L7 is the one the plugin returned on the previous execution, so the language service returned by the plugin ends up doubly decorated.
🙂 Expected behavior
When plugin's create is called, info.languageService should contain an fresh object that doesn't have the decorations from the previous execution.
Additional information about the issue
No response

This is intended. We do not check if plugin has patched LS instance and whatever LS instance we have will be passed around. This is to ensure that if there are multiple plugins, they can still handle the patching correctly.
Plugin should handle whether they need to patch LS instance or just data associated with it.

There's no need to check if the LS has been patched, it's sufficient to keep the original LS and use that to create a new LS to pass to plugins on each reload.
I have a fix here: https://github.com/vemoo/TypeScript/tree/fix-plugin-reload specifically this commit: https://github.com/microsoft/TypeScript/commit/9239728f931e7e356cad06daa4f9320fb7b56c8d
Otherwise in my opinion the documentation here https://github.com/microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin is incomplete because it suffers from the issue I describe.

It depends on how you handle the patching of LS .. you can always check if it’s already patched which your example is not doing and hence patching it again

Ok, I see now that for example the angular plugin is doing this:
https://github.com/angular/angular/blob/ced66d4007784de1ed38d7fcd82fd1c6db9b8436/packages/language-service/src/ts_plugin.ts#L17
where getTypescriptLanguageService is:
https://github.com/angular/angular/blob/ced66d4007784de1ed38d7fcd82fd1c6db9b8436/packages/language-service/src/ts_plugin.ts#L200
and isNgLanguageService is:
https://github.com/angular/angular/blob/ced66d4007784de1ed38d7fcd82fd1c6db9b8436/packages/language-service/api.ts#L64
Which effectively means that getTypescriptLanguageService will always return the LS passed on the first call to create. Which I feel is a bit weird because it assumes the previous languageService is still valid.
I still think there will be existing plugins that are not checking because https://github.com/microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin and https://github.com/orta/TypeScript-TSServer-Plugin-Template don't check.
I'll close the PR and leave this issue for the documentation.

authors: sheetalkamat vemoo


text:
Un-initialized class fields are omitted from the emitted JS, compared to the field counterparts in JS

🔎 Search Terms
field, initializer, uninitialized, class, getOwnPropertyDescriptor
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about class fields

⏯ Playground Link
https://www.typescriptlang.org/play/?ts=5.5.4#code/MYGwhgzhAEAKD2BLAdgF2gbwFDWgDwC5pkBXAWwCMBTAJ2gB9oTkATKgMxSpYG4doAnkVKVaDJqw5deWAL5YsweMgjoADtAC8xKgHc4SNAAoAlAqUr4IKgDoQ8AOZGA8hQBWVYKhsOqqZ7rIsDTwarSoAgAiVBDANIhqqPA0RmoANNAA5HiZJmZAA
💻 Code
class Point {
  x: number | undefined;
  y: number | undefined;
}

const p = new Point()

console.log(Object.getOwnPropertyDescriptor(p, 'x'))

🙁 Actual behavior
The output of Object.getOwnPropertyDescriptor(p, 'x') is undefined. This is because the property is completely omitted from the emitted JS:
class Point {
}

🙂 Expected behavior
One would expect the class to be emitted as the below, valid JS which is analogous:
class Point {
  x
  y
}

Where the output of Object.getOwnPropertyDescriptor(p, 'x') would be the present descriptor.
Additional information about the issue
This is disruptive for example when unit testing with jest, where a test case like the below is invalid:
it('mocks a property on the class', () => {
  const p = new Point()
  jest.replaceProperty(p, 'x', 25);
  // ^ fails the test with 'Property `x` does not exist in the provided object'
  // see https://github.com/jestjs/jest/blob/0d96de975783ee78192c1037862ea3089f52dc25/packages/jest-mock/src/index.ts#L1302
})

A workaround is to add initializers:
class Point {
  x: number | undefined = undefined;
  y: number | undefined = undefined;
}

In which case the properties are correctly set in the emitted JS.

Marked this as a bug, since an unsuspecting developer migrating code from JS to TS like the following:
class Point {
  x
  y
}

would be introducing functional changes to their program by virtue of renaming the file to .ts, despite the identical syntax, which could be a source of bugs.

This is working as intended. You either need to target ES2022 or later, or turn useDefineForClassFields on.

You either need to target ES2022 or later

Can you share an example? Try it in the playground link shared above and there was no difference.

Try it in the playground link shared above and there was no difference.

The default value for useDefineForClassFields depends on the target. When the target is set to ES2022 or later, then the default is true. However, the playground does not support default values for compiler options, and in your playground link useDefineForClassFields is set to false.

authors: MartinJohns loucadufault


text:
Fix crash in assigning function with this ref to alias

Fixes #34647

[ ] There is an associated issue in the Backlog milestone (required)
[x] Code is up-to-date with the master branch
[x] You've successfully run gulp runtests locally
[x] There are new or updated unit tests validating the change

Nice catch, thanks @Knagis!

@RyanCavanaugh @DanielRosenwasser here's another one that should be in 3.7.2.

@typescript-bot cherry pick this

Argghh
@typescript-bot cherry-pick this
And next time reply "I don't know how to cherry pick this"

@typescript-bot cherry-pick this to release-3.7
And next time reply "Where should I cherry-pick this to?"

authors: Knagis sandersn


text:
Skip typedef in services get js doc tags

Skip @typedef and @callback tags when generating quickinfo for a declaration. They are unattached tags that happen to be attached to a particular node because of the way the compiler works.
Skip comment text from jsdocs that contain only @typedef and @callback tags. Again, these are attached because of an implementation detail.

For example:
/**
 * This is skipped in f's quickinfo
 * @typedef {number} N - and this tag is skipped completely
 */
function f() { }
/**
 * This is NOT skipped because of the param tag
 * @typedef {string} S - but this still is
 * @param {S} x
 */
function g(x) { }

The idea is that the comment text of a jsdoc that contains other tags probably describes both tags.
This is big-ish change in a poorly tested area of services (though with fourslash baselines, it's getting better!). I don't think this should go into 4.3.
Fixes #43534

@mjbvz You might have an opinion about this as well.

From editor meeting:

People thought it was a good idea overall.
Might make the heuristic stricter -- require a newline to skip a whole jsdoc, and maybe include the typedef in a jsdoc that has other tags. Need to look at existing usage, especially for the former.
Need to correctly handle @property and @param inside @typedef and @callback respectively. (The parse tree might make this work already, but it needs a test.)

 /**
  * This is NOT skipped because of the param tag
  * @typedef {string} S - but this still is
  * @param {S} x
  */
 function g(x) { }

It seems fairly useful to preserve this typedef in the quick info for g, since otherwise it may be hard to know what S is. If this “local alias” pattern is the majority of typedefs mixed into comments with other tags, I would say it’s fine to preserve them, and try to instead filter out whole doc comments that seem to be purely typedef-like.
The problem is, it may be hard to reason about what doc comments are “purely typedef-like” from their tags:
/**
 * @deprecated
 * @see Some newer type that you should use instead
 * @author Andrew Branch
 * @typedef {Object} Foo
 * @property {string} email
 * @property {number} whatever
 */

function foo() {}

Two alternative strategies for deciding what comments to remove come to mind:

For a given doc comment attached to a node, if that doc comment includes @type, @param, or @returns, include everything in that doc comment in the quick info, because clearly those tags are supposed to apply to some declaration/expression, not just stand alone as a typedef declaration. Any embedded typedefs are probably contextually relevant to that node, or else the author would have written them somewhere else. If the doc comment doesn’t contain any of those declaration/expression-affecting tags, but does contain a @typedef, treat the entire doc comment as a standalone declaration and don’t show any of it in the quick info for the following node.
For a doc comment that contains a @typedef and some other stuff, use a blank line between the end of the comment and the following node to indicate that none of that doc comment should be included in the node’s quick info.

Andrew's point 2. makes the most sense to me.

I'd rather vote for the strategy 1 and avoid significant blank lines.

I looked at my usual corpora [1] to see which strategy is best. I started by considering three options:

Exclude the whole comment for comments containing a @typedef/@callback and no @param or @return tags. (Strategy 1 proposed by @andrewbranch)
Exclude the whole comment for comments containing only @typedef, @callback and perhaps a small set of associated tags.
Exclude the whole comment for comments containing a (OR only) @typedef/@callback if a newline separated the comment from the next element in the source. (Strategy 2 proposed by @andrewbranch)

I found all comments containing @typedef and dumped the list of tags from each comment.
.ts files
.ts files had almost 300 @typedef, about 250 single @typedefs. The remaining typedefs were in 3 projects:

openfin and google-gax used @summary, @desc and @example to explain the typedef further.
protobufjs used a @callback-like variant of @typedef that Typescript doesn't parse:

/**
 * @typedef {function} Typename
 * @param {number} a
 * @param {string} b
 * @return {string}
 * @this {?object} Please don't pass `this` it is the worst.
 */

Also, notably, in protobufjs, the @typedefs are often immediately followed with a Typescript declaration for the same thing. I think the .d.ts files were generated from Closure @typedefs.
.js files
.js files had more than 8000 @typedef, 7500 single @typedefs. The remaining typedefs fell into 4 categories:

embellishments for documentation or structure like @summary, @description, @category, @public, @module, @global, @static, @interface, @example, @throws. There was a lot of variety here.
'local' typedefs that were immediately used with a @param and @return tag (the typedefs are not actually local to the declaration)
@callback-variants like the protobuf example above, which also used @param and @return tags. (and @this, once or twice)

6 projects use the unsupported callback-like typedefs compared to 3 projects that use local typedefs.
Additionally, I observed plenty of unassociated @typedef comments that were not separated by a newline from the next element, though the median next element was another comment.
Analysis
The best rule for excluding typedefs in quickinfo is (1). Except for local typedefs, all typedef-containing comments that I saw were exclusively about that typedef. And, although both local typedefs and callback-like typedefs are rare, it's better to show a few callback-like typedefs than to hide local typedefs that were intentionally defined in-place. (2) won't work well because there it's too hard to capture the set of associated tags -- we would end up showing any unforeseen variants needlessly. And the data show that (3) is both unnecessary and ineffective.
In the future, if we decide to support callback-like typedefs, then (1) would stop incorrectly showing the callback-like typedefs. The code to implement this wouldn't be large, although I think there isn't much demand.
[1] A full install of Definitely Typed, using @definitelytyped/dtslint-runner to npm install every package inside types/, then find . -iname '*.ts'. The same for the user tests in the TS repo.

authors: andrewbranch jessetrinity sandersn thorn0


text:
vscode can open and modify source.list through GUI but can't save

I know that /etc/apt/source.list is a file that should not be modified freely, but sometime i need to modify the package to speed up download speed so it has to be changed. One way to do that is through VIM. VIM is a headache for me (a deep-rooted windows user). I can open /etc/apt/source.list in VSCODE as the following picture below, but after modifing it, saving it is a another headache because I don't have root 's rights. "Permission Denied". Any workaroud?

This is a dupe but I can't find it. Ref microsoft/vscode-remote-release/286.

Any workaroud?

It might take if you (re)start WSL as root (wsl.exe -u root). Haven't tried (wouldn't try). Humble guidance would be to use nano.

... or SOP would be to copy the /etc/apt/sources.list to $HOME, edit it in VS Code, and copy it back to with sudo(1).
Closing rather than let it chirp crickets indefinitely. Right now, by-design, WSL interop leans heavily on the "default user" paradigm. For the unprivileged multi-user use case (user steve or jane), follow the vscode-remote-release tracker cited above. Maybe something will come of it.

repo: microsoft/WSL


text:
WSL Corrupted Windows 10 Dell XPS?

Environment
Windows 10 (unsure of exact version but would be latest up to date personal)
Windows build number: [run `cmd.exe /c ver`]
Your Distribution version: [On Debian or Ubuntu run `lsb_release -r` in WSL]
Whether the issue is on WSL 2 and/or WSL 1: [run `cat /proc/version` in WSL]

WSL 1
Steps to reproduce

WSL logs:
Expected behavior

Actual behavior

I am not 100% sure if WSL is the issue but figured it would be safer to report than not. After starting WSL on Windows 10 Dell XPS 15 9530 I changed directory a few times and did code . into one of my ruby projects as per usual however as soon as I did this, all applications on my computer froze and eventually after trying to ctrl alt delete without any luck I got a black screen only able to move the cursor.
When trying to start up the laptop I now get a internal hard disk not found error, no bootable devices.
After running hardware diagnostics all hardware is fine. Changing bios boot options however doesn't resolve anything. This would then seem like the OS is the issue and I was curious as to whether WSL specifically did something to corrupt windows.
Unable to provide any logs as not many people have a mini ssd reader that is necessary for these dell xps models and will likely just have to reformat with a new bootable OS anyway.

That sounds like an excessive use of resources. Try reducing the RAM used for WSL2. See this.

WSL 1
Is your project in a /mnt/* folder? Try copying that folder in a /home/* one and call code . from there.

Update: After trying different bios settings and Windows Repair tools, I was unable to boot Windows and therefore had to reinstall Windows which has wiped everything. There is no Windows.old folder so I doubt I can recover anything or provide any logs.

WSL 1

Is your project in a /mnt/* folder? Try copying that folder in a /home/* one and call code . from there.

My projects were simply in a projects folder.
I think your previous comment might have been onto something if an excessive use of resources could have caused the crash and corruption of Windows 10 but if that was the case I'd say there is a fundamental issue with WSL if that is how it handles the crashes. My RAM and/or CPU usage would have been quite high at this point so this seems plausible.
The other explanation that people have mentioned is that Windows released a big update the day I had the crash which supposedly could have caused issues with my firmware as it is 5 years old and wasn't updated.

Update: After trying different bios settings and Windows Repair tools, I was unable to boot Windows and therefore had to reinstall Windows which has wiped everything. There is no Windows.old folder so I doubt I can recover anything or provide any logs.

WSL 1

Is your project in a /mnt/* folder? Try copying that folder in a /home/* one and call code . from there.

My projects were simply in a projects folder.
I think your previous comment might have been onto something if an excessive use of resources could have caused the crash and corruption of Windows 10 but if that was the case I'd say there is a fundamental issue with WSL if that is how it handles the crashes. My RAM and/or CPU usage would have been quite high at this point so this seems plausible.
The other explanation that people have mentioned is that Windows released a big update the day I had the crash which supposedly could have caused issues with my firmware as it is 5 years old and wasn't updated.

ehm mine is 10 years old at this point and I doesn't get any problem with it. Anyway if it lead to no bootable found then there're problem on disk driver, that lead to spin until it's overheat and cause it can't be detected by the computer. I've seen that many times on my lab, especially if it's old HDD running windows 10.

When trying to start up the laptop I now get a internal hard disk not found error, no bootable devices.

Whoa! Sounds like WSL tried to replace your operating system. Don't try to use it next time if you're not sure what you're doing.

When trying to start up the laptop I now get a internal hard disk not found error, no bootable devices.

Whoa! Sounds like WSL tried to replace your operating system. Don't try to use it next time if you're not sure what you're doing.

Not sure what I am doing? I was sure of what I was doing, very basic commands. If this was a bug in WSL, it wasn't anything to do with my inputs

Not sure what I am doing? I was sure of what I was doing, very basic commands. If this was a bug in WSL, it wasn't anything to do with my inputs

Oh… sorry for the confusion. Perhaps your hard disk failed and corrupted the Windows 10 installation when running WSL?

authors: DanPinGF benyaminl onomatopellan puremana


text:
No Internet with WSL on system with multiple LAN addresses

Version
Microsoft Windows [Version 10.0.19044.1620]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
5.10.16.3-microsoft-standard-WSL2
Distro Version
Ubuntu
Other Software
No response
Repro Steps
Install WSL
Open Ubuntu
sudo bash
apt-get update
Expected Behavior
Updates to download and install, Ubuntu to be usable.
Actual Behavior
Updates do not download, and Ubuntu cannot access internet.
Diagnostic Logs
I have by hand determined this to be due to the network setup here.
The system is used to manage machines on two separate networks, 192.168.0.x and 192.168.1.x
The system only has a gateway on one network, so all internet traffic should flow out that.
Instead, it seems WSL is trying to use the network with no gateway.
If I remove the management network IP address and reboot the system, then everything's ok.
PS C:\Users\Owner> ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : DEV01
Primary Dns Suffix  . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Network:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Intel(R) Ethernet Connection (5) I219-LM
Physical Address. . . . . . . . . : 10-E7-C6-37-6A-67
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.0.130(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IPv4 Address. . . . . . . . . . . : 192.168.1.248(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.254
DNS Servers . . . . . . . . . . . : 192.168.1.245
192.168.1.246
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter VirtualBox Host-Only Network:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Physical Address. . . . . . . . . : 0A-00-27-00-00-0A
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::491b:ad05:f303:2621%10(Preferred)
Autoconfiguration IPv4 Address. . : 169.254.38.33(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 470417447
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-F8-08-9A-10-E7-C6-37-6A-67
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter vEthernet (Network):
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
Physical Address. . . . . . . . . : 00-15-5D-EC-5F-A3
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::64a1:3882:6328:ed47%19(Preferred)
IPv4 Address. . . . . . . . . . . : 172.31.0.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 318772573
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-F8-08-9A-10-E7-C6-37-6A-67
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter vEthernet (Default Switch):
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
Physical Address. . . . . . . . . : 00-15-5D-D0-24-E8
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::7514:d2bf:ba01:1157%32(Preferred)
IPv4 Address. . . . . . . . . . . : 172.28.0.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 536876381
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-F8-08-9A-10-E7-C6-37-6A-67
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter vEthernet (VirtualBox Host):
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
Physical Address. . . . . . . . . : 00-15-5D-35-65-3F
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::1d8d:40ba:df9e:6835%38(Preferred)
IPv4 Address. . . . . . . . . . . : 172.28.80.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 637539677
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-F8-08-9A-10-E7-C6-37-6A-67
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter vEthernet (WSL):
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
Physical Address. . . . . . . . . : 00-15-5D-A0-14-0C
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::51ac:b097:7d02:4304%44(Preferred)
IPv4 Address. . . . . . . . . . . : 172.30.144.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 738202973
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-F8-08-9A-10-E7-C6-37-6A-67
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled

/logs

authors: MilesTFox OneBlue


text:
Quizzes translated to Spanish

Added my translations to the quiz-app by adding following ES file: https://github.com/microsoft/Web-Dev-For-Beginners/tree/main/quiz-app/src/assets/translations/es.json
Added my Spanish (ES) language code to the dropdown in the quiz-app's App.vue file
Edited the quiz-app's translations index.js file to add my language

thank you!!! gracias!!!

authors: alequetzalli jlooper

repo: microsoft/Web-Dev-For-Beginners


text:
Mouse Right Click

There is no way to simulate a right button click and for some windows application it was very useful.

Hi, I'd like to do ContextClick on my own coordinates since control is not possible to define by UIInspect. how could I define coordinates on my own?
I need something like: session.Mouse.ContextClick(MyOwnCoordinatesDependingOnControlCoordinates);

Hi, I'd like to do ContextClick on my own coordinates since control is not possible to define by UIInspect. how could I define coordinates on my own?
I need something like: session.Mouse.ContextClick(MyOwnCoordinatesDependingOnControlCoordinates);

Try moving the mouse where you want to click based on offsets:
session.Mouse.MouseMove(session.FindElementByName("ElementName").Coordinates, 145, 391);
session.Mouse.ContextClick(null);
This will Context Click with an offset of 145, 391 from the element named "ElementName".

yep, offsets are the best, thanks :-)
пт, 27 сент. 2019 г. в 20:23, James Palmer notifications@github.com:

Hi, I'd like to do ContextClick on my own coordinates since control is not
possible to define by UIInspect. how could I define coordinates on my own?
I need something like:
session.Mouse.ContextClick(MyOwnCoordinatesDependingOnControlCoordinates);
Try moving the mouse where you want to click based on offsets:
session.Mouse.MouseMove(session.FindElementByName("ElementName").Coordinates,
145, 391);
session.Mouse.ContextClick(null);
This will Context Click with an offset of 145, 391 from the element named
"ElementName".
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WinAppDriver/issues/343?email_source=notifications&email_token=AKER6JA4AIHUVH65SJQBANLQLY6SBA5CNFSM4EMSGQE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ZSEMA#issuecomment-536027696,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKER6JHQVGBR3W2RA2UD6ADQLY6SBANCNFSM4EMSGQEQ
.

authors: FBorges14 Soloveykos jpalmer-miovision

repo: microsoft/WinAppDriver


text:
sample

Which sample are you reporting a bug in?
Example: ResizeAppView
Describe the bug
A clear and concise description of what the bug is.
Include links to specific lines of code where you think the bug is.
(Click the line number, then click the "..." and select "Copy permalink.")
If not sure, at least include a link to the scenario where the problem is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Configuration

Language/architecture/flavor: (example: C++/WinRT x64 Debug)
Windows platform and build number: (example: Desktop build 18362.)

Visual Studio version: (example: 16.6.5; get this value from Help.About.)

Additional context
Add any other context about the problem here.

Template not filled out.

repo: microsoft/Windows-universal-samples


text:
XAML visual designer does not show in WinUI 3 Desktop project.

Describe the bug
Xaml designer does not appear in my visual studio or blend. when I click the MainWindow.xaml, only the XAML text shows. However,  the same XAML file can be edited with the visual designer  in a UWP project.
Steps to reproduce the bug

Steps to reproduce the behavior:

create a new WinUI 3 project,
Click on MainWindow.xaml

Expected behavior
An visual XAML designer appears just like UWP.
Screenshots
Xaml designer does not appear in my visual studio or blend within a WinUI3 Desktop project.

it works on a UWP project with the same contents.

Version Info
both project 0.5.5 and 0.5.6
NuGet package version:
A VCPKG Nuget package.

Windows 10.019042
Additional context
My colleagues also meet the same bug.

Not really a bug, seems that the designer will not be implemented until WinUI 3.0 ships. See #3656.

Adding a direct link to the related WinUI issue https://github.com/microsoft/microsoft-ui-xaml/issues/3656#issuecomment-730558094
I don't think this is something we can expect any time soon....

Adding a direct link to the related WinUI issue microsoft/microsoft-ui-xaml#3656 (comment)
I don't think this is something we can expect any time soon....

Thank you. It was available in a Preview Vision of WinUI 3. I did not expect it removed.

I get exactly the same behavior. Neither Blend nor VS 2019  will show a design surface for WinUI 3. I spent a lot of time trying to understand what I was missing , then found this thread.  If it will not be implemented "until WinUI 3 ships" I understood WinUI 3 HAD shipped and was now part of Reunion 05.
Will we get an update for VS 2019? How will I know when I can develop with WinUI 3?
Thanks.

@MoreporkGithub It's not that it won't be implemented until WinUI 3 ships,  it's that it won't be considered until after WinUI 3 (WinAppSDK v1.0) ships.
It seems more effort is being put into Hot Reload and Visual Studio Live Preview (which will both, eventually, be available for WinUI 3) instead.
Hopefully, these tools will enable a suitably comparable experience and also bring other benefits in the future too. (Especially as Hot Restart improves.)
If your past XAML development experience has been heavily reliant on the visual designer then I can appreciate a big impact to your productivity. :(

Thanks mrlacey, for your comment.
I've had to give up on it for now.
I did my first UWP project a few days ago using XAML for the first time, but I was really keen to try the new WinUI 3.
I have a lot of experience with Windows Forms and C# and have written tools to generate Windows Forms, but XAML is new to me and I have been working to understand it.
Obviously, we get used to the convenience of a Design surface and  I struggled to use XAML without one. I located the WinUI 3 library and tried cutting and pasting XAML code to see if I could get some controls onto a form but I was never able to make it work.
Thanks for your comment (I have no idea what "hot reload" is but I'm sure I'll find out in time.)

There is no solution, issue should be reopened.

Same issue here, how come such a major thing gets vanished.

And VS2022 does not allow a designer or Blend for VS2022!!! Nespa?

Same issue

same here :( brig designer back pls...

Same issue

No design view, no datagrid. Who TF is going to use WinUI 3??

ITNOA

@MoreporkGithub It's not that it won't be implemented until WinUI 3 ships, it's that it won't be considered until after WinUI 3 (WinAppSDK v1.0) ships.
It seems more effort is being put into Hot Reload and Visual Studio Live Preview (which will both, eventually, be available for WinUI 3) instead. Hopefully, these tools will enable a suitably comparable experience and also bring other benefits in the future too. (Especially as Hot Restart improves.) If your past XAML development experience has been heavily reliant on the visual designer then I can appreciate a big impact to your productivity. :(

It is ship, so what is your plan?

related to https://github.com/microsoft/microsoft-ui-xaml/issues/5917

@mrlacey

@soroshsabz I don't work for Microsoft and I'm not on the core team for WAS or WinUI. As per the discussions linked above, the lack of direct feedback from the team about this over the last few years, and the resource prioritization from Microsoft, I can't imagine Microsoft building this.

@soroshsabz I don't work for Microsoft and I'm not on the core team for WAS or WinUI. As per the discussions linked above, the lack of direct feedback from the team about this over the last few years, and the resource prioritization from Microsoft, I can't imagine Microsoft building this.

This is the scary part. I'm a big fan of WinUI, WindowsAppSDK and the whole Reunion thing. But it does not feel like Microsoft is going all in on in this.

I think a MSFT representative should just announce whether there will ever be a designer for winui or not, and then we can all give this issue thread a break once and for all.
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Matt Lacey @.>
Sent: Monday, June 26, 2023 5:24:03 PM
To: microsoft/WindowsAppSDK @.>
Cc: Nafis Ahmed @.>; Comment @.>
Subject: Re: [microsoft/WindowsAppSDK] XAML visual designer does not show in WinUI 3 Desktop project. (#766)
This is the scary part. I'm a big fan of WinUI, WindowsAppSDK and the whole Reunion thing. But it does not feel like Microsoft is going all in on in this. Feels more like an afterthought, a pet project that could be axed any time like so many others before.
There's a need for an abstract, realist view when it comes to building native Windows apps.
Firstly, Microsoft has publicly committed to the ongoing support of WindowsAppSDK & WinUI3. They're building parts of the OS and key applications with it. This is, in part, intended to show that they are committed to it.
Secondly, it's important the be realistic that the number of people building native Windows apps and the number of Windows apps is much smaller than it used to be and also much smaller than the number of people building for the web. As a business, Microsoft has a lot more invested in web-based development and, therefore, invests more in this area.
"going all in" is open to interpretation. While it would be great if money, time, and resources were no object to Microsoft when creating WAS & WinUI and the related tools, documentation, functionality, etc. but that's--sadly--not the case.
This view shouldn't be a reason to give up on the technologies though, especially if you're a fan and able to use them to achieve the results you're looking for. You may benefit from looking beyond what is only provided by Microsoft. I also advise looking at how you're writing XAML. If it's not changed from what you'd write a few years ago, there are almost certainly opportunities to apply conventions and best practices so that it's easier to write, read, understand, and maintain.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/WindowsAppSDK/issues/766#issuecomment-1607715080, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHZ3PUHPKEKLO22PSNC3OEDXNGSRHANCNFSM43UEVINQ.
You are receiving this because you commented.Message ID: @.***>

I think a MSFT representative should just announce whether there will ever be a designer for winui or not, and then we can all give this issue thread a break once and for all.

They have essentially, during the WinUI community calls.  They word it as "not planned", or "not a priority"...

authors: MoreporkGithub Slion Zaryob ZhouJJJKKK acrigney artsemionov martin999a mdtauk michalss mrlacey rollinbe rvxfahim sidy3d soroshsabz

repo: microsoft/WindowsAppSDK


text:
Add DeploymentRepairOptions

Add DeploymentRepairOptions to Repair API
Update GetStatus to also verify PackageStatus when the WinAppSDK Main and Singleton packages are installed and return PackageRepairRequired if status is not ok in which case, the developer can call Repair API to repair the packages.

API spec at https://github.com/microsoft/WindowsAppSDK/pull/2869

/azp run

/azp run

/azp run

/azp run

/azp run

neither the spec nor the implementation has ever landed since then. what's the latest update on this one?

@sachintaMSFT  neither the spec nor the implementation has ever landed since then. what's the latest update on this one?

authors: mominshaikhdevs sachintaMSFT


text:
[Build] Fix obsolete area path for filing TSA bugs on the Foundation repo

The same changes as in Pull Request 11512903 but here for the Foundation repo instead.
--
A microsoft employee must use /azp run to validate using the pipelines below.
WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.
For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

/azp run


text:
Email all users setup in "App Center => Application => Collaborators" for every new crash

Describe the solution you'd like
Add a "new" feature in "App Center" to notify "App Center => Application => Collaborators" as soon as "App Center" identifies that a "New Crash" has occurred.
Describe alternatives you've considered
As an alternative, the current option available with "App Center" is to setup "Email Notifications" only when a "New Crash Group" is created.
Additional context
Benefits with "new" feature proposed is to allow IT organization be more proactive in taking required corrective & preventive actions "before" the end-user (who faced the app crash issue) reports the app crash issue to IT organization.

Hi @dkangala - thanks for submitting a feature request! It sounds like your team would like a notification for each individual crash that occurs instead of a only notification for a new crash group. Is my understanding correct?

Yes @winnie, You are correct

authors: dkangala winnie

repo: microsoft/appcenter


text:
Build status email notifications

Describe the solution you'd like
I would love to get build status email notifications (passed/failed/etc.)
Describe alternatives you've considered
In AppCenter, there is no dashboard with the current build status. If an organization has multiple apps with multiple builds running on a regular basis, checking build status requires visiting each app's build page to see build execution results.
Additional context
Add any other context or screenshots about the feature request here.

Hey @vmalyi - you can manage your email notifications in your app settings page.

It's a bit hidden but the email settings we have should meet the solution requirements you described. Let me know if that's not the case.
I've also linked a few feature requests similar to your note about app dashboards:
https://github.com/microsoft/appcenter/issues/1184
https://github.com/microsoft/appcenter/issues/1567
https://github.com/microsoft/appcenter/issues/937
Feel free to give them a +1. Thanks!

authors: vmalyi winnie


text:
Export crash/error data to Application Insights

Describe the solution you'd like
Currently, it is possible to export only analytics data to Application Insights,  you cannot export crash/error data to Application Insights.
Exporting crash/error data is possible only to Blob Storage, but this is not convenient for data querying and identifying issues.
I would like to have support to export crash/error data to Application Insights.
Describe alternatives you've considered
There are alternative solutions, but none of them is convenient:

Do not export crash/error data - analyzing errors and crashes in AppCenter doesn't give powerful querying capabilities as Application Insights
Export to Blob storage - same problem, it is difficult to query data
Use AppCenter APIs - overkill, need to develop a separate tool just to efficiently query the errors/crashes

Hi @alexaconstantin - this isn't on our immediate roadmap but it's definitely on our radar. I'll keep an eye out on this thread and post with any updates. Thanks!

I would like to echo @alexaconstantin.  We have all of our dashboards, queries and alerts coming from Application Insights for our web and desktop applications.  It works great.  However, because app center does not allow for the export of errors and crashes we cannot tie our Xamarin application into how we do everything else.  Application Insights has an exceptions bucket where the crashes and errors would fit very nicely, it even has a handledAt field that is used to say if it was unhandled or usercode handled.
Please reconsider the priority of this feature or suggest some alternatives that would allow us to get the data into Application Insights.  I am seriously considering having to write our own mechnism to translate the blob storage exports into app insights data.

Hi, We also need this. Currently its limitation for us in choosing AppCenter -> Application Insigths workflow. It will be very helpful to export diagnostic/crash into Application Insights.
Please reconsider priority for this feature.

Very important feature for mature products.
I'm currently trying to export errors into blob and query it with PoweBI, however errors do not seem to be exporting right now. I used to be able to do it in the past.
Providing an easier solution that resolves this issue is needed at this stage of this product.

Hi @winnieli1208. Are there any updates on this feature request? I would appreciate if you could increase the priority considering that other users consider this very useful and there is no convenient workaround. Thank you!

Apologies for the delay. This is something we'd like to support in the future but unfortunately, I don't have an ETA. Our team is focused on the items listed on our roadmap at the moment. I encourage everyone to follow our roadmap and iteration plan to see what our team is up to.
I'll post here if I have any updates. Thanks!

I think this priority needs re-assessed, being able to export only analytics and not errors is quite a big shortfall of app centre. Errors are what most people would want to export out to application insights for querying. Currently, the crashes section of the app centre portal does not provide enough customization or ability to query data in any direct detail to compensate for this. So I think myself and a lot of people agree we would like to see this sooner rather than later. Thanks :)

@winnieli1208 this is a very important feature I think @Jspoors32  nailed it quite well. is there a workaround possible, which you can provide some example scripts? Maybe copy errors via API´s ?

We definitely feel the absence of this feature, please reconsider the priority of this request. Thanks!

@winnieli1208 I think this very important for distributed solution, especially for logs correlation between back end and apps. The azure blob storage logs is simple unusable for large scale logging.

We really need to have everything at ONE place, meaning exporting crash/error data to Application Insights is highly demanded!

Hey all - I understand Azure Blob storage isn't an ideal experience for many use cases. Our team would love to support this but we're currently working through our backlog and don't have the bandwidth for this feature at the moment. We are actively monitoring these feature requests to help us define our roadmap and I really appreciate all the helpful comments. Please continue to share your feedback.
@aumanjoa - we have a list of APIs for our diagnostics service listed here that will return your crashes and errors data but as mentioned, you would still need to do extra work for any querying or customizable functionalities.

It seems that UnhandledErrorLog and HandledErrorLog events are created at the time of a crash/error, respectively, but with little information beyond the timestamp and normal device telemetry. It would be great if those events could at least include the crash/error group identifier that's used in the AppCenter URL. It would be even better to track them as AppInsights exceptions instead of customEvents (but with correct user_Id/session_Id; cc #151) with proper stack trace and custom properties.

Hi @winnieli1 !
This feature was implemented?
PS: Not sure if this is the best place for this issue.
The "HandledErrorLog" event, on the Application insights portal, exists two properties: "User Id" (Custom Event Properties section) and "UserId" (Custom Properties section).
What information is this?
In the application, it was called only the method "Crashes.TrackError (ex);"
Regards.

@felipebrito1 hmm it indeed does seem like errors are coming through as Events in Application Insights, with the event name HandledErrorLog! However, there's zero useful info in the event... not even the exception type, message, or method that it failed at.

As for the difference between User Id and UserId...
User Id == The App Center auto-generated identifier to track the user (so you can correlate events performed by that user. It's in the format of a GUID.
UserId == Whatever you specified when you call AppCenter.SetUserId(accountId.ToString()). I set that to my user's online account ID, so when a user has an issue, I can look up any errors they had in App Center by searching by their User ID (account ID in my case).

Yep, I'm waiting patiently for this as well...

So it's almost a year, since this feature was request in first place, but it still did not make in on the roadmap?
I just used up a lot of time to get export of errors and crashes to blob storage, hoping that there is a way to get the blob storage into azure analytics without great effort, but unfortunately support told me in the end of this process that what I want is not possible yet.
I do really hope that there will be a short term solution for this issues.

Does anyone have a workaround for this using blob storage export?
I also agree with others, this is important for our team since we are trying to use application insights as single source for analytics and troubleshooting.

I'm logging an analytics event every time I log an exception

We are in need of this feature as well... or maybe a better and easier way to search errors within App Center

I'm logging an analytics event every time I log an exception

This is really going to be the only solution. Currently I am running an Azure Function that calls the API and inserts them into Table Storage. Now I'm trying to figure out how to get them into App Insights. I can't believe we can't do this easily. I also have them all dumping into a single blob storage account that I configured through the REST API since you can't choose to exclude the analytics data unless you do that. So now I have data both in Table Storage and Blob storage, but not in App Insights. So frustrated.

In my team, we are logging a custom event whenever we log an error:
Crashes.TrackError(ex, dictionary);
Analytics.TrackEvent("HandledErrorDuplicate", dictionary);
It duplicates the error information, but the error data in the dictionary will end up in App Insights.

I am now doing this. But we can't get all the information that is in the crash logs into an event. Doing the best we can, but it's not ideal. Would like to be able to use the Exceptions area of App Insights like we do for web and services.

Definitely need error information exported to application insights. My app uses primarily errors instead of crashes. The error comes over simply as HandledErrorLog with no pertinent content. Will try to log a custom event to improve the situation for now. Had also considered logging the error directly to application insights. Not sure if there would be issues trying to match a user reported via app center export vs user reported via directly error log to application insights.

Hi @winnie, are there any updates on this?

Hi @winnie, any update on this, please.

I see that exceptions are now being passed to App Insights, but not having crashes sent over is a big step backwards - the older HockeyApp product did used to include that feature, and our monitoring displays are built to pull the telemetry from AI, so would be a big step forward to have this feature included going forward.

Hi @winnie, are there any updates on this?

Hey all - I don't have any updates. Our team is focused on improving reliability and performance for App Center for the rest of the year and to around mid-2021. Because of this, we won't be making much progress around most feature requests.

Big need and desire for this functionality. I get needing to postpone requests until mid-2021, but I really hope this is at the top of the list once requests start being implemented again.

We have been waiting for this feature for quite some time now. We ended up using another tool for analyzing crash and error logs.

We have been waiting for this feature for quite some time now. We ended up using another tool for analyzing crash and error logs.

We would also need this feature!

As mentioned before, the crashes and errors exported to insights don't take enought information, it should take the error message and the stacktrace for instance into the custom properties of the events generated.
please review this.

+1

+1. To point out this not stale and should not be auto-closed.

+1. To point out this not stale and should not be auto-closed !!
Pls. review your Backlog and give priority to this feature

+1 Please consider implementing this issue. With HockeyApp at least there were fewer limitations, so we could just log stacktraces to Application Insights, but with AppCenter, we can't even do that.

The lack of this feature is making the AppCenter --> Application Insights integration unusable for production ready failure maagement.

Any news to add this feature in export?

I was wondering why the Failures section of our app's Application Insights was empty after several app crashes... well now I know why.
With MAUI gaining traction (along with Windows App SDK), I hope this and other issues are addressed and Microsoft puts much more resources in App Center development. However, until a major announcement from the App Center team (if there is one) I won't hold my breath for this to be resolved.

Any updates on this? It's been almost four years since this issue opened, and I'm still puzzled why this is not considered an essential part of logging. AppCenter itself lacks the extensive querying possibilities of AppInsights, rendering it nearly useless to do troubleshooting with.

For anyone willing to spend some effort and $$, we've implemented the following workaround:

Enable integration with storage account (including raw crashes / errors - "export_entities": [ "crashes", "errors" ])
Use a logic app with an event grid connector, a get blob content and a send data to log analytics workspace actions

You might have to do some filtering at the Event Grid System Topic Subscription level or at the Logic App level  (sample path for an error  archive/2023/01/30/15/01/errors/aa1310fd-2df9-41d5-8d9b-9da51bd6a667.json, sample path for a crash archive/2023/01/30/15/01/crashes/3a2d0075-1949-4369-8733-53ce59aa41ac.json)

Profit

I think you should use Sentry (instead of appcenter as they added support for Xamarin

Any updates on this?

Any updates on this?

Any news on this?

Almost 5 years and no progress. It hasn't even received a token "this is very important to us" in 3 years!

Was there any update on this?
At the very least if we could have the error properties be exported as part of the HandledErrorLog, so that they can be correlated later to App Center, that would vastly improve our experience when investigating issues.

authors: Fampov Jitendrakandpal11 Jspoors32 Maverick1st Monsteel Mostlypyjamas TDishop alexaconstantin andrewleader asavvop aumanjoa chipcarden citpo cosminstirbu dahlbyk dahliaingabire-okta dimitarcnbs fareshan felipebrito1 fraxedas jfranki jstawski ksaunder manfredczujan marioingemann markbeij mxstudios onurarpapay ramit-2343113 sasivishnu sirmmacias slurpo stealthjong2 thisisthekap tijlreynhout wickiie winnie winnieli1208 wouterattoptal wouterst79