text:
Bug: Intellisense shows misleading error when parameter is expected to be a union of an object and a string

Bug Report
🔎 Search Terms
Intellisense, incorrect function parameter
🕗 Version & Regression Information
Tried with v4.3.5
⏯ Playground Link
Playground
💻 Code

declare const send:
  (event: { type: "A", foo: string } | { type: "B" } | "B") => void

declare const sendOnlyObject:
  (event: { type: "A", foo: string } | { type: "B" }) => void

send({ type: "A" })
// Type '"A"' is not assignable to type '"B"'.(2322)

sendOnlyObject({ type: "A" })
// Argument of type '{ type: "A"; }' is not assignable to parameter of type '{ type: "A"; foo: string; } | { type: "B"; }'.
//   Property 'foo' is missing in type '{ type: "A"; }' but required in type '{ type: "A"; foo: string; }'.(2345)

🙁 Actual behavior
The error for send({ type: "A" }) is Type '"A"' is not assignable to type '"B"'
🙂 Expected behavior
The error should be something like the one for sendOnlyObject or at least not misleading that the property type has to be "B" that's what is getting suggested here.

It's probably the case that we bail early in findMatchingDiscriminantType because of the primitive. If it's not too hard and it's not too expensive, the fix is likely to create a union of only object types, match on the discriminants of the union, and elaborate on that type.

I'm not sure if it's related, but I've just hit TS2345 on this:
const func = (foo: boolean | "bar") => {}
func(1 != 2 && "foo")

with argument to func failing with
TS2345: Argument of type '"" | "foo"' is not assignable to parameter of type 'boolean | "bar"'.   Type '""' is not assignable to type 'boolean | "bar"'.
(this contrived example also gives TS2367 but we don't care about that)
It looks like for some reason, if | with a string, first false is resolved as "" instead

Is the problem fix in v4.5.2?

Neither OP nor mine is fixed on 4.5.2

authors: DanielRosenwasser MonstraG devanshj ldwonday


text:
Support different moveToNewFile file name conventions

Suggestion
Support additional file naming conventions when refactoring.
🔍 Search Terms
moveToNewFile move to file "move to a new file"
✅ 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
Specify project file naming conventions in tsconfig.json and use the rule here.
📃 Motivating Example
Angular projects use the file name convention some-example.component.ts. The refactor action "Move to a new file" uses the convention SomeNewFile.ts. Ideally, there would be a way to specify the naming convention of the new file. In this case, some-new-file.ts would be the desirable outcome.
💻 Use Cases

Create a TS interface in the same file where it's being used called SomeExampleInterface
Extract the interface using "Move to a new file" in VS Code
Notice the created file is SomeExampleInterface.ts, which needs to be renamed to some-example-interface.ts to follow project naming conventions

This would be great if it could be supported!

To save others time trying to find this issue.
Related: https://github.com/microsoft/vscode/issues/81835

This issue has been resolved. You can choose an arbitrary file name via "Move to File" then "Enter a new file path".
https://github.com/microsoft/TypeScript/assets/2646053/1fc1f5a0-b48d-4825-ae3f-e7da0fddb5cc

This issue has been resolved. You can choose an arbitrary file name via "Move to File" then "Enter a new file path".
move-to-file.mov

I would not say it is completed. You need to type in the file name, but the original request was about adding file name conventions, so you can do refactor faster.

@BartaG512 Allowing the user to specify a file name seems like an elegant and satisfactory way to solve the problem I originally reported. Please feel free to open a new issue if the solution isn't satisfactory for your use case.

This should be reopened as this does not fix the issue stated in the OP.

I always want my filename to be the kebab case version of my function name. The solution as stated is hardly different than Move to new file -> rename. In fact, with autocomplete it's worse, as it's easy to accidentally move to an existing file with a similar name.

That's exactly what I'm after @chad-schwab. Since I work a lot with react and want my components to be capitalised in code but kebab case in the file name.

Re-opened, this is no longer an issue for me, but it seems it's still an issue for others. I'll let the company with more resources and time figure out what to do about this 😮💨

source: gharchive/issue

repo: microsoft/TypeScript

license_type: permissive

license_source: github-api


text:
User-defined type guards cannot narrow discriminated union types

Bug Report
🔎 Search Terms

user-defined type guards

narrowing

discriminated union

🕗 Version & Regression Information

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

⏯ Playground Link
Playground link with relevant code
💻 Code

type FooBar<T = 'foo' | 'bar'> = T extends string ? { type: T; value: Capitalize<T> } : never;

declare const fooBar: FooBar;

const isFoo = (type: 'foo' | 'bar'): type is 'foo' => type === 'foo';

if (fooBar.type === 'foo') {
    // 'Foo'
    fooBar.value
}

if (isFoo(fooBar.type)) {
    // 'Foo' | 'Bar' ???
    fooBar.value
}

🙁 Actual behavior
typeof fooBar.value in the second if block is 'Foo' | 'Bar'
🙂 Expected behavior
typeof fooBar.value in the second if block should be 'Foo' instead of 'Foo' | 'Bar'

Duplicate of #42384.

authors: MartinJohns yenshih


text:
'this' operator cannot correctly deduce the type

Bug Report

🔎 Search Terms

🕗 Version & Regression Information
4.9.4

This is a crash
This changed between versions ______ and _______
This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
I was unable to test this on prior versions because _______

⏯ Playground Link

Playground link with relevant code
https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgLIG8CwAoZy4BcIArgLYBG0Oe5BAzmFKAOY4C+OOoksiKA0gB5UyCAA9IIACZ1kAe3IArCAjAA+LLmRgAngAcIBANYQdcmGmrIAbnAA2xQ2gDaYABbA6zgOS6D3gF0AqwQPOykoCBAAfgIhVDVnYOwObBwEORAGZDE44TUAXmRNPD9DbzhvABorWwdyujpq5AB6FpAICCltNyg5AHdRKD6oELCIqIJnKzwSvHmyggAiciWarXmbe0cCACZW9s7u9z7B6BGZ5FS8ZLYgA
💻 Code

// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.
//  - The sample is confusing or doesn't clearly demonstrate what's wrong.

interface M{
  a:number
  b:string
}

interface K<M extends object>{
  type:keyof M
  value: M[this['type']]
  children?:K<M>[]
}

const x:K<M>= {
  type:'a',
  value:'ss', //need throw error
  children:[
    {
      type:"b",
      value:2 //need throw error
    }
  ]
}

🙁 Actual behavior

no error
🙂 Expected behavior

need error

A bare reference to a type isn't something that performs generic inference; K<M> is effectively the same as if you had written this type instead:
type KM = {
  type: keyof M;
  value: M[keyof M];
  children?: KM[];
}

authors: RyanCavanaugh janryWang


text:
require() has a type of any

Does this issue occur when all extensions are disabled?: I think yes.

VS Code Version: 1.77.0
OS Version: Windows 10

I don't think that I can describe any reproduction steps. It became so suddenly, and I tried to restart VS Code, and change the workspace, but it's still like this.

Also, because of this, IntelliSense for required packages doesn't work at all.

What is the bug here? What are you expecting to happen?

It sounds like you have the node .d.ts in one file, but not in the other.

It sounds like you have the node .d.ts in one file, but not in the other.

What do you mean?

It looks like this is a question rather than a bug report. This issue tracker is for tracking bugs and active work on TypeScript itself, rather than a general forum for programmers using TypeScript to get help or ask questions.
You can ask questions on sites like Stack Overflow. We are not able to provide one-on-one support on the issue tracker. Please read the issue template carefully - it has important information on what kinds of reports can be acted on here, as well as links to useful TypeScript resources. Thanks!

authors: NightNutSky RyanCavanaugh


text:
Passed generic not giving exact return type in callbacks

🔎 Search Terms
"exact return type", "generic return type", "return type excess property checks"
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about exact types, return types, generics and excess property checks

⏯ Playground Link
https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABABwIYCdUFsDOAxcCAHgBUA+ACjUywC5ESBKRAbwF8BYAKFElgUQQARgUilKw+hWYBeMg2btu3KAE9kAU0QBZVSXVaZrbolOJgcOPRxR0MMAHNunLtwD0bxAEEciAO5aqAA2QYgA1mBwfigY2L4YWrYaqFAaACaIqL4aAB6o0Ihqmr5+MFAAFogOGmAadhA43NRxosS6+pqULOaW9ADkQhh9ADSIg+j9gwBefWyMylweiABCIFCF5TC+W4iR6xVaEFlafuU1G1o42FrVtfWIOyA46ZnxiOgaUCDoSEUa3MJWkR2gZKNJEHJEBQWCYzBYrIgBkNhrDTONJqgZs5GPNXItPKt1jBgIgAJKIXLIIIwCBlIKqQoGB5QUZlRA4EBpNI1en+ODoMLxByoewAkSEYF6UEUaT0EGaCHyaGonoIpHoEYq9GI6Z9bGMIA
💻 Code
function paramsFunc<T>(param: T) {}
function cbFunc<T>(cb: () => T) {}

type MyType = {
    foo: string
}

// As we all know params are treated as exact types with generics. "bar" gives an error
paramsFunc<MyType>({ foo: 'bar', bar: 'baz'})

// But this is not the case when the same generic is used as a return type. "bar" does NOT give an error
cbFunc<MyType>(() => ({
    foo: 'bar',
    bar: 'baz'
}))

// But if I explicitly type it, it suddenly works again. "bar" gives an error
cbFunc<MyType>((): MyType => ({
    foo: 'bar',
    bar: 'baz'
}))

🙁 Actual behavior
When passing an explicit generic, when that generic is used as a return type, the excess property check is not running
🙂 Expected behavior
When passing an explicit generic, the excess property check should run regardless of how that generic type is used
Additional information about the issue
As a library author you might provide callbacks to some public API of the library to generate values. These callbacks can have a return type that needs to be defined by the consumer of the API. In library world you typically pass required types as part of some constructor as the type is used to infer different aspects of consuming the API. Currently library authors has to either:

Document that consumers has to both pass the type as a generic and explicitly use it as a return type on the callbacks
Create an artificial utility function to trigger excess property check on the params to the utility function, just to return the param

An example of this would be:
type State = {
  status: 'ON'
} | {
  status: 'OFF'
}

type Event = {
  type: 'TOGGLE'
}

const transitions = createTransitions<State, Action>({
  ON: {
    TOGGLE: () => ({ status: 'OFF' })
  },
  OFF: {
    TOGGLE: () => ({ status: 'ON' })
  }
})

In this example the excess property check is not triggered for the return type of these callbacks, even though the State generic was explicitly defined. As mentioned in the points above, you would need to either have to remember to explicitly add the return type to the callbacks:
const transitions = createTransitions<State, Action>({
  ON: {
    TOGGLE: (): State => ({ status: 'OFF' })
  },
  OFF: {
    TOGGLE: (): State => ({ status: 'ON' })
  }
})

This is easily missed as there is nothing initially indicating that a type is missing. It is only when you start changing the types that you have unused and confusing properties that is not part of the type, but is not erroring either.
Or you can:
const transitions = createTransitions<State, Action>((transition) => ({
  ON: {
    TOGGLE: () => transition({ status: 'OFF' })
  },
  OFF: {
    TOGGLE: (): State => transition({ status: 'ON' })
  }
}))

But this makes the API more verbose than necessary and the utility function makes no sense for someone consuming the library without TypeScript.
Sorry if this is already an addressed issue, but it seems to sit between generics, exact return types and esxcess property checks... so difficult to pin down if this is a bug, something that requires changes to TS or is expected behaviour. If this is expected behaviour I want to argue that explicitly typed generics should trigger excess property checks.
Thanks a bunch for taking the time to look through my issue 😄

This is essentially a duplicate of #241. Check the linked issues.

Thanks for the reference @MartinJohns! My "Excess property checks on return types" search did not hit  "widen return types" it seems 😂
But okay, great. I also see there was a design discussion on this https://github.com/microsoft/TypeScript/issues/56965.
It seems it is planned to be fixed, hm

Okay, so I get a response that the referenced discussion (https://github.com/microsoft/TypeScript/issues/56965) is related, but not a fix for this issue. So yeah, not sure how much attention this deserves and how to ensure it gets that deserved attention 🤔

Not sure if this is considered related, but this also doesn't work:
cbFunc<MyType>((): MyType => {
    const value = {
        foo: 'bar',
        bar: 'baz'
    }

    return value
})

@essenmitsosse That is working as intended. The type of your variables inferred to { foo: string; bar: string } due to the lack of type annotation, and when returning the value the compiler only checks compatibility. { foo: string; bar: string } is compatible with the type { foo: string }.
See the FAQ entry: (Indirect) Excess Properties Are OK

It's probably time for my once-every-few-years attempt to look at #241 again and see what doesn't work these days

authors: MartinJohns RyanCavanaugh christianalfoni essenmitsosse


text:
missing used props type in generated d.ts file when generate typs from JavaScript

🔎 Search Terms
dts infer type missing
🕗 Version & Regression Information

This changed between versions 5.5.4 and 5.6.2

⏯ Playground Link
No response
💻 Code
Below is a minimal reproduce of JavaScript code.
export class ViewPluginBase {
  constructor({ name, customUiKeyMap = undefined } = {}) {
    this.viewName = [null, undefined, ''].includes(name) ? this.constructor.name : name;
    this.customUiKeyMap = customUiKeyMap;
  }
}

export class ViewPlugin extends ViewPluginBase {
  constructor({
    name = 'ViewPlugin',
    customUiKeyMap,
    useDefaultClass = true // may change name for easier understand meaning
  } = {}) {
    super({ name, customUiKeyMap });  // <- customUiKeyMap is being used here but generated type lost it

    if (useDefaultClass) {
      console.log("print here to simulate useDefaultClass is used");
    }
  }
}

🙁 Actual behavior
I use npx -p typescript tsc src/**/*.js src/*.js --declaration --allowJs --emitDeclarationOnly --strictNullChecks --outDir dist to generate d.ts for me in one of my JavaScript lib and the behavior changed recently when I found the type changed between 5.5.4 and 5.6.2 . I do not find any clue yet so I raised a bug, but if you find it expected changes per the upgrade, feel free to mark it as more reasonable type, thx!
Now 5.6.2 generated type is
export declare class ViewPluginBase {
    constructor({ name, customUiKeyMap }?: {
        customUiKeyMap?: undefined;
    });
}
export declare class ViewPlugin extends ViewPluginBase {
    constructor({ name, customUiKeyMap, useDefaultClass }?: {
        name?: string | undefined;
        useDefaultClass?: boolean | undefined;
    });
}

🙂 Expected behavior
export declare class ViewPluginBase {
    constructor({ name, customUiKeyMap }?: {
        name: any;
        customUiKeyMap?: undefined;
    });
}
export declare class ViewPlugin extends ViewPluginBase {
    constructor({ name, customUiKeyMap, useDefaultClass }?: {
        name?: string | undefined;
        customUiKeyMap: any;
        useDefaultClass?: boolean | undefined;
    });
}

Additional information about the issue
5.5 playground result

link: https://www.typescriptlang.org/play/?ts=5.5.4#code/KYDwDg9gTgLgBAYwDYEMDOa4DUCWwDuACkgK4DmOAdgELrBwDeAUHIhJWjFCQjNABQM4lFAFtgAGkQlOEUQFUcAaWABPALIowcALxwSlACbAAZlWCG4AX12MrASkYtWcGAAscaAHQA3PPgA5MXo9AG1KEiQkKQNjM0oLKQByJIBdLypkEmM0fhFxRwB+Vw9vBHZObl5oL3z6AC5hYIBuZ1Z3Ty8EGT4FZTVNbT1u2T6VDS1W1ismGaZQSFhEVAxsf2JyKjhQGGAjTFwCDYoaOidWco4uHj4oQTam8Vskw6JSE6SJB5HexXHBr4ufRoYAAEVMKEiMAAwitMHprvQAPRIuCiFCqRBuFCUMj0OpwEzQbboPBQfRGYBQTg4yziHFUMjOGx6BgOc4uNAkMBUwSPSTSUZ-AZaaz2KYuB44ExwfgyMEQqGw9BoRzMIEXCoQJDALxICBkfgAIjAUCo8DcVPofDgaBwokiKF2wIVJkhSBhcLgnhdhiN4oeM2msyAA
5.6 playground result

link: https://www.typescriptlang.org/play/?ts=5.6.2#code/KYDwDg9gTgLgBAYwDYEMDOa4DUCWwDuACkgK4DmOAdgELrBwDeAUHIhJWjFCQjNABQM4lFAFtgAGkQlOEUQFUcAaWABPALIowcALxwSlACbAAZlWCG4AX12MrASkYtWcGAAscaAHQA3PPgA5MXo9AG1KEiQkKQNjM0oLKQByJIBdLypkEmM0fhFxRwB+Vw9vBHZObl5oL3z6AC5hYIBuZ1Z3Ty8EGT4FZTVNbT1u2T6VDS1W1ismGaZQSFhEVAxsf2JyKjhQGGAjTFwCDYoaOidWco4uHj4oQTam8Vskw6JSE6SJB5HexXHBr4ufRoYAAEVMKEiMAAwitMHprvQAPRIuCiFCqRBuFCUMj0OpwEzQbboPBQfRGYBQTg4yziHFUMjOGx6BgOc4uNAkMBUwSPSTSUZ-AZaaz2KYuB44ExwfgyMEQqGw9BoRzMIEXCoQJDALxICBkfgAIjAUCo8DcVPofDgaBwokiKF2wIVJkhSBhcLgnhdhiN4oeM2msyAA

Duplicate of https://github.com/microsoft/TypeScript/issues/59920 , see the @ahejlsberg's recent comment there

authors: Andarist Rvtea


text:
Optimize source mapping into external source map sources

Fixes #40054
Timings

fn
Before
After
Improvement

emit phase
13.4
8.8
-34%

emitSourcePos
4.8s
0.6s
-87%

setSourceMapSource
4.3s
0.1s
-98%

Shucks, we really should have run a perf test on this.
@typescript-bot perf test this

well duh, that'll do nothing now.

source: gharchive/pull-request

authors: DanielRosenwasser JoostK


text:
Can't acces WSL files/mapped drive from certain windows programs

Windows Version
Microsoft Windows [Version 10.0.22631.2715]
WSL Version
2.0.9.0
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
5.15.133.1
Distro Version
Ubuntu 22.04
Other Software
Scribus, Windows 64 bit and Windows 32 bit, version 1.5.8
owncloud client, Windows 64 bit, version 5.2.0
Repro Steps

Map \\wsl$\Ubuntu-22.04 to drive letter Z: (tested via "net use" and Windows Explorer)
Open certain windows programs (in this case: Scribus and Owncloud)
Try to add folder on mapped drive as sync folder (Owncloud) or open files from it (Scribus)

Expected Behavior
The file dialogue should list the WSL drive and allow to add/open the files/folders inside.
Actual Behavior

For Scribus: the mapped drive does not show up at all. A mapped network share on the local network does however show up there.
For Owncloud: the desired folder can be selected in the setup assistant. It does not allow however to add the folder as sync destination, complaining about missing write permissions.

Diagnostic Logs
Opening files from WSL in Windows Explorer or most other applications (tested: GIMP, Adobe Reader, Windows Photo Viewer, ...) works flawlessly.

This is a problem for me as well. Perhaps the problem lies with Scribus?

authors: fschicker mgamble

repo: microsoft/WSL

license: MIT


text:
[RESOLVED] apt-get: relocation error on dist-upgrade to Xenial

I'm creating a cross-reference for this failure:  The root cause (and the fix) is upstream, but I just hit it and looked for the solution here; I'm filing this ticket so that others who look for the fix here can find it.
WSL forum mods, feel free to close this either right away (since I think there's no action for the WSL team to take here) or once most people have upgraded to 16.04.
I recently ran do-release-upgrade to upgrade to Xenial.  After the upgrade, many commands, including apt-get, failed with:
$ sudo apt-get install dialog
apt-get: relocation error: /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0: symbol _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE7compareERKS4_, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

This is caused by Ubuntu #1572903.  The workaround listed there, which worked for me, is as follows:
wget http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.2_amd64.deb
sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.2_amd64.deb

I just hit this on 15063.13 after a do-release-upgrade. Updated workaround (package build has been updated):
wget http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.4_amd64.deb
sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.4_amd64.deb

Thank you @raymens. It works.
We can close this issue.

When I run that wget command it results into error :
Resolving security.ubuntu.com failed. Temporary failure in name resolution

Now it says Error 404 not found.

I've hit it just now, and here's the updated workaround that worked for me:
wget http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.12_amd64.deb
sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.12_amd64.deb

Thanks, @gumb0 the libstdc library you referenced above resolved my upgrade from 14.04 to 16.04 (desktop was cycling through login).

Thanks @gumb0 , that worked for me too.

I signed up just to add @gumb0  this still works.
Thank you for the help.

I've hit it just now, and here's the updated workaround that worked for me:
wget http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.12_amd64.deb
sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.12_amd64.deb

Thanks a lot for this, After going through on this for hours, finally found a solution that worked. Thanks a lot.

Thanks a lot for the hint. I had to combine it with a bit more work to install other conflicting related packages: https://askubuntu.com/questions/1437928/problem-when-upgrading-ubuntu-14-to-ubuntu-16?noredirect=1#comment2507795_1437928

authors: HLFH Shrek-DevMasterRobo aseering fabianlee ferdymercury gumb0 jca-agnitio raymens rush5150 zkawan


text:
WSL2 stops working

Windows build number:  Microsoft Windows [versão 10.0.18956.1000]
I use the following command to access my WSL2 machine:
wsl -d Ubuntu-18.04
Yesterday it stopped working, when I ran the command I received the following message:
The attempted operation is not supported for the type of object referenced
Logs collected:
logs.zip
Already tried to restart the computer and I still receive the same error.
Things that I've done yesterday:
I run ipconfig /release and ipconfig /renew and updated Docker Desktop Tech Preview.
(Already tried to uninstall Docker Desktop and still got same error)
wsl -l returns two distros that I have installed (got same error on both of them):
Ubuntu-18.04 (Default)
Ubuntu-16.04

The following command fixes the problem:
netsh winsock reset

#4177


text:
[WSL] No such file or directory when setup environment

Windows Build Number
Microsoft Windows [Version 10.0.19041.1110]
WSL Version

[ ] WSL 2
[X] WSL 1

Kernel Version
4.4.0
Distro Version
Ubuntu 18.04
Other Software
No response
Repro Steps

append new line export NODEJS="/mnt/d/wsl/node" to the end of  ~/.bashrc
start wsl and appear: -bash: export NODEJS=/mnt/d/wsl/node: No such file or directory
but is avaliable to access this directory in wsl, see the screen capture

Expected Behavior
use file (outer of wsl) as environment variables of wsl
Actual Behavior
fail to setup
Diagnostic Logs
No response

i restore the ~/.bashrc and redo these again, and it works!
i can make sure that i alway use LF instead of CRLF in ~/.bashrc, maybe it is due to \n and \r\n ?


text:
Windows .exe execution is very slow when .exe is in WSL filesystem

Version
Microsoft Windows [Version 10.0.22621.521]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
5.15.57.1
Distro Version
Ubuntu 20.04
Other Software
No response
Repro Steps
# Copy a Windows executable file to WSL file system
cp /mnt/c/WINDOWS/system32/whoami.exe /tmp
# Execute copied Windows .exe from WSL's filesystem
/tmp/whoami.exe

Expected Behavior
Windows executables run quickly in WSL.
Actual Behavior
Executables from /mnt/c run quickly. Same executables copied into WSL's Linux's filesystem run horribly slow.
WSL hangs for a long time when starting execution of a Windows .exe file. During the hang it doesn't respond to interrupts such as ctrl + c.
$ /mnt/c/WINDOWS/system32/whoami.exe exec time 0s
$ /tmp/whoami.exe exec time 90 s
Diagnostic Logs
WslLogs-2022-10-04_14-00-34.zip

I'm encountering the described behavior with all .exe files I've tried so far including 3rd party apps and stock Windows programs like in the provided example.

Based on the kernel version, I'm assuming you are using one of the pre-release Systemd WSL versions?  Is this a new problem that you are experiencing only under that release or did the problem occur on "stock" Windows 11 WSL?

I encountered the same problem. As @NotTheDr01ds said, I removed wsl preview (now the kernel version is back to 5.10.102.1-microsoft-standard-WSL2 ) and the problem was fixed.

@lucidfrontier45 In the hopes of narrowing this down a bit, you might want to try:

If you were using an earlier pre-release, try the latest one (currently 0.68.4 and see if the problem persists.

If the problem persists there, then try 0.66.2 since that was the last release before the Systemd changes.  I'm expecting you won't have the problem in that release.

I'm not able to reproduce this myself using (currently) 0.68.2 or 0.68.4 on two different systems, so there's likely something system-dependent in the issue as well, it seems to me.

@NotTheDr01ds Could you share me any document for installing specific version of WSL? I'll happy to test those version.

No problem:

wsl --shutdown

On the releases page here, expand the "Assets" for the release you want to try

Download the .msixbundle

Open an Admin PowerShell and run:
cd <download_folder>
Add-AppxPackage <package_filename>

Sometimes you need to reboot before it will release the files from the old version, but that shouldn't be a problem the first time since you are using the "stock" WSL installation at the moment.

@NotTheDr01ds thank you so much. Can you also tell me how to revert to the shock WSL?

Here is a simple benchmark program.
https://gist.github.com/lucidfrontier45/c83a58ff423f26dc0feb9ce84ea8f836
I compiled it in Ubuntu 22.04 on WSL2 with mingw.
/usr/bin/x86_64-w64-mingw32-g++ --std=c++17 -O3 --static main.cpp

1 Running the result a.exe inside WSL
$ ./a.exe
s = 2.49998e+07
elapsed = 2.179[sec]

2 Running it from Windows
PS D:\share> .\a.exe
s = 2.49998e+07
elapsed = 1.631[sec]

3 Running Linux binary built by g++ --std=c++17 -O3 --static main.cpp
$ ./a.out
s = 2.49998e+07
elapsed = 1.351[sec]

The above result is obtained from preview version WSL. (Installed by wsl --update in Windows Powershell)
With stock WSL, 1 and 2 result the same duration.

another benchmark, just memory allocation and free.
https://gist.github.com/lucidfrontier45/c83a58ff423f26dc0feb9ce84ea8f836#file-main2-cpp
1 a.exe inside WSL
/mnt/d/share/a.exe
elapsed = 11.487[sec]

2 a.exe in Windows
PS D:\share> .\a.exe
elapsed = 5.282[sec]

3 native Linux
$ ./a.out
elapsed = 0.612[sec]

Whether the .exe is in WSL filesystem or not is irrelevant. Whether we call it from Windows or WSL matters. Perhaps I should submit a separate issue.

@lucidfrontier45 You can uninstall the Preview just like you do with any Store application.  After uninstalling (typically no reboot required), you'll be back to the built-in WSL release.
So, for example:

wsl --shutdown
Hit the 🪟 (Windows) key to bring up the Start menu
Start typing "Subsystem"
Right-click on the "Windows Subsystem for Linux Preview" result in the Start menu
Select "Uninstall"

Of course, you can also do the same through the "Add or Remove Programs" settings.

@NotTheDr01ds
Thank you for sharing how to install/uninstall.
I tested the benchmark programs which I posted above. In both 0.66.2 and 0.68.4 the performance degraded. Only in the stock WSL the .exe called from Windows and one called from WSL ended in the same duration.

Hi I am experiencing the same on:
C:\work>wsl --version
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.1105
What version shall we revert to? I believe I am using the stock install..?

I made benchmarks using the main2.cpp provided above:
win11 native cmd: elapsed = 6.8[sec]
wsl2 1.03: elapsed = 12.692[sec]
wsl2 0.66.2: elapsed = 12.621[sec]
wsl2 1.1.2: elapsed = 10.262[sec]
Could you please elaborate what your "stock" version is?

@boborjan2
Stock WSL is what is bundled in the Windows. If you can use wsl --version command, then it is installed from the Microsoft Store app and thus is not stock WSL.
Unfortunately, Microsoft is going to remove the stock WSL in the future.
https://www.xda-developers.com/windows-11-dev-channel-25272/

I made a test with wsl kernel 5.10.102: using wsl version 1.1.2, kernel version does not make any difference.

Executing the .exe encapsulated in cmd.exe /c does the trick for me.

For me, it's not only that .exes within WSL filesystem are slow, but also even exes outside WSL are slow if launched with a $PWD that is inside WSL.  But if you launch them with a PWD of /mnt/c and then use some means (eg powershell's Start-Process -WorkingDirectory) to set the correct working directory from the windows side, then it's nice and fast.

Yes I also experienced that. I wonder if encapsulating in cmd/c only makes it faster because of pwd of cmd must be set to non-wsl dir anyhow (it does not support unc paths).

I confirm: even without cmd.exe, the execution is fast (i.e comparable to native windows) if the cwd of the .exe is non-wsl AND the .exe itself is located on a non-wsl fs. Otherwise it get can terribly slow.

For me, it's not only that .exes within WSL filesystem are slow, but also even exes outside WSL are slow if launched with a $PWD that is inside WSL. But if you launch them with a PWD of /mnt/c and then use some means (eg powershell's Start-Process -WorkingDirectory) to set the correct working directory from the windows side, then it's nice and fast.

I observed the same thing too. It is kind of odd, it only happened to certain computers.
It becomes very slow whenever I try to access /mnt/c. But some computers work perfectly fine. I only see this happened to Windows 11.

It becomes very slow whenever I try to access /mnt/c. But some computers work perfectly fine. I only see this happened to Windows 11.

I am on Windows 10.  I think I occasionally observed even just ls being super slow to list files in /mnt/c, but it's been a while since I've seen that.  Launching exes is consistently slow though.
It always seems to be just over 10 seconds for me which makes me wonder if there could be some kind of timeout going on.

It becomes very slow whenever I try to access /mnt/c. But some computers work perfectly fine. I only see this happened to Windows 11.

I am on Windows 10. I think I occasionally observed even just ls being super slow to list files in /mnt/c, but it's been a while since I've seen that. Launching exes is consistently slow though.
It always seems to be just over 10 seconds for me which makes me wonder if there could be some kind of timeout going on.

What is your Windows version? It seems working better with Windows version: 10.0.22621.1265

What is your Windows version? It seems working better with Windows version: 10.0.22621.1265

Mine is 10.0.19045.2604

I have this too: starting Windows executables from WSL2 filesystems first hands the program for ~90 seconds, then it runs.
Looks like there is a wait for some timeout to pass...

My issue might have been different, but since upgrading to WSL 1.1.3.0, my seemingly related problem seems to have been resolved.  whoami.exe in the Windows filesystem is now fast.  When copied to the Linux filesystem, while it's noticeably slower, it only takes ~0.2 seconds for me.

Redirection to cat for every command help for me, but seems MS don't want to revolve this issue.
e.g.
wsl.exe --update | cat

It does not seems to be a pure kernel problem. I've got an instance with Linux kernel 5.15.90.1, which does not hang starting windows executables from WSL2 filesystem:
$ cp /mnt/c/Windows/system32/whoami.exe .
$ time ./whoami.exe
xxx\yyy

real    0m0.054s
user    0m0.000s
sys     0m0.003s

$ uname -a
Linux xxx 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Fixed for me by updating WSL to latest kernel: 5.10.102.1-microsoft-standard-WSL2
WSL2 Linux kernel updates: https://www.catalog.update.microsoft.com/Search.aspx?q=wsl

Thanks for sharing your findings!
I've tried to install 5.10.102.2 version following your link. Starting wsl_update_x64.msi throughts the error:
Starting This update only applied to machines with the Windows Subsystem for Linux.
Updating with wsl.exe --update brings kernel 5.15.90.1, which is still affected by the issue:
$ time ./whoami.exe
xxx\yyyg

real    1m20.500s
user    0m0.004s
sys     0m0.000s

Thanks for sharing your findings! I've tried to install 5.10.102.2 version following your link. Starting wsl_update_x64.msi throws the error:
Starting This update only applied to machines with the Windows Subsystem for Linux.
Updating with wsl.exe --update brings kernel 5.15.90.1, which is still affected by the issue:
$ time ./whoami.exe
xxx\yyyg

real    1m20.500s
user    0m0.004s
sys     0m0.000s

Same issue for me with kernel 5.15.90.1
❯ time whoami.exe

Executed in   18.13 secs      fish           external
usr time    2.62 millis   58.00 micros    2.57 millis
sys time    0.23 millis  231.00 micros    0.00 millis

Hi,
This is happening for me regardless of which WSL kernel version I am using.
It happens to me if I use the bundled  WSL that comes with Windows (The wsl.exe in C:\Windows\System32\wsl.exe), but also if I use the WSL that you can install from the Microsoft store (App name: "Windows Subsystem for Linux"). I tried to run both "Debian" and "Ubuntu" distributions, and it happens on both.
$ time /mnt/c/WINDOWS/system32/whoami.exe
xx\yyyy

real    0m0.363s
user    0m0.002s
sys     0m0.000s

$ time /tmp/whoami.exe
xx\yyy

real    2m0.210s
user    0m0.001s
sys     0m0.000s

Also, this is happening since some time on the old WSL1, even if I did not do any WSL changes (before the exes were running fine). Then I tried to install WSL from Microsoft store, install Ubuntu distribution, but the very same issue is happening.
My current WSL version:
wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3208

The "bundled" wsl.exe that is in the Windows System32 folder has a File version: 10.0.10941.2311.
Interestingly, when running WSL, the "new" WSL still runs as a child process of the "bundled" WSL (but I guess that's expected right?):

I think it's still an issue. Is there an update?


text:
Automatically run UI Tests after build

Describe the solution you'd like
I would like to automatically run UI Tests on a given build
Describe alternatives you've considered
There is one guy that figured out how to run UI tests through hackery:
https://tomsoderling.github.io/AppCenter-Automated-UI-tests-on-build/
Additional context
This would be very useful

Here's a post-build script I wrote to build my Xamarin.UITest project and push it to App Center Test:
https://github.com/brminnick/UITestSampleApp/blob/master/Src/UITestSampleApp.iOS/appcenter-post-build.sh

Yes, this would be very helpful. Not needing to create a custom post-build script.

Thanks for the feature request and to those adding their support. We'll continue to track this as a potential new feature. Thanks to @brminnick for your example as well!

How did you include the provisioning profiles? I keep getting the following error for provisioning profile? How does one resolve these errors? I spent hours on this..nothing worked!!! :/
error: No profiles for 'com.xyzorg.appname' were found: Xcode couldn't find any iOS App Development provisioning profiles matching 'com.xyzorg.appnamer'. (in target 'TargetName')
error: No profile for team 'ABCABC1234' matching 'DevProfileName' found: Xcode couldn't find any provisioning profiles matching 'ABCABC1234/DevProfileName'. Install the profile (by dragging and dropping it onto Xcode's dock item) or select a different one in the General tab of the target editor. (in target 'TestTargetUITests')

@hemantbavle1 I used to use Bitrise.io in the past, they have a nice tool called codesigndoc, which gathers all the necessary profiles needed. I used it for AppCenter as well, just skipping the last step (uploading to Bitrise) and just uploaded the needed files generated to AppCenter manually.
Here is a link to their documentation for codesigndoc.

I still think this is a good idea, one of the main features of competing CI/test runners is running UI tests as part of the build pipeline (as well as in parralell). Can we reopen it please?

I wonder why this is yet again marked as closed. It should actually not be that hard to simply hook up the two steps build and test with each other. They did manage to do the same for build and distribute as well after all.

authors: GrayedFox brminnick craig95 hemantbavle1 kericbowman nikoAurich nrajpurkar

repo: microsoft/appcenter


text:
Robot Framework + Appium support for Automated Testing

Describe the solution you'd like
Since we already have appium support in AppCenter, I would like to suggest an integration with RobotFramework that can run automated tests using an Appium Server.
Describe alternatives you've considered
Haven't considered any alternatives.

I'd like to renew this request.

me too, this will come in handy for my company projects.

Same here. It'd be very much anticipated to have the possibility to upload RobotFramework tests to AppCenter

same here. this feature would be very helpful!

Hi All! Thanks for reaching out.
We are not planning to add support for this in the near future.

authors: CmosII IlyaBausovAkvelon lofi96 mike14u neothXT vitorandrietta


text:
Issue while building the Flutter application iOS Version.

Describe the bug
While building the Flutter application we are facing below issues :
PhaseScriptExecution Run\ Script /Users/vsts/Library/Developer/Xcode/DerivedData/Runner-emuvnsfaoizvsegonkoohmlhzhko/Build/Intermediates.noindex/ArchiveIntermediates/qa/IntermediateBuildFilesPath/Runner.build/Release-qa-iphoneos/Runner.build/Script-9740EEB61CF901F6004384FC.sh
(1 failure)
##[error]Error: /usr/bin/xcodebuild failed with return code: 65

Hey, @v2Nitesh, thanks for getting in touch - can you elaborate a bit, and provide some context about what is going on?
From what you provided it is quite troublesome to understand the problem.

Hey, @v2Nitesh, thanks for getting in touch - is it the same problem?

No This is not the same problem. Both are diffrent.
https://github.com/microsoft/appcenter/issues/700
https://github.com/microsoft/appcenter/issues/701

@v2Nitesh thanks for opening the bug, we'll take a look at this. As an FYI, App Center Build does not officially support Flutter today.

@v2Nitesh I'm removing the bug label on this as we don't officially support Flutter.

App Center Build does not officially support Flutter.

authors: Jamminroot nrajpurkar stephan-markovic v2Nitesh


text:
Fix small typo in the docs

Why are these changes needed?
There's a small typo in the docs and I'd like to fix it :)
Related issue number
NA
Checks

[x] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[x] I've added tests - NA
[x] I've made sure all auto checks have passed.

Merge into the 0.2 branch

repo: microsoft/autogen


text:
Java code-to-cloud

Build and deploy Java apps from source or Jar to Azure Container Apps

This is now GA based on https://techcommunity.microsoft.com/blog/appsonazureblog/announcing-the-general-availability-of-java-experiences-on-azure-container-apps/4238294

authors: dariagrigoriu simonjj

repo: microsoft/azure-container-apps


text:
Multiple TEE-CLC processes with high memory usage are spawned by Rider

There are four (!) processes which host TEE-CLC instances:

Each process uses about 630 MB of memory. 630 x 4 = 2520 MB (2.5 GB)
This seems as unnecessary waste of computer resources and bug: why several processes are needed? Why there cannot be single process?
Details for one of processes:

Yeah, I've noticed this, too, and I think it will be fixed by #354. Some of the workspace runners were incorrectly introducing their own cache entries (that were never reused).

authors: ForNeVeR streamstr

repo: microsoft/azure-devops-intellij


text:
"Resource file has already set to" warning at the KubernetesManifest@0 task

Required Information
Question, Bug, or Feature?
Type: Bug
Enter Task Name: KubernetesManifest@0
Environment
Azure Pipelines
Both of the Microsoft Hosted and On-Premise agents
Issue Description
We are started to getting this error at the beginning of all KubernetesManifest@0 tasks.
==============================================================================
Task         : Deploy to Kubernetes
Description  : Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts
Version      : 0.181.0
Author       : Microsoft Corporation
Help         : https://aka.ms/azpipes-k8s-manifest-tsg
==============================================================================
##[warning]Resource file has already set to: /home/vsts/work/_tasks/KubernetesManifest_dee316a2-586f-4def-be79-488a1f503dfe/0.181.0/node_modules/azure-pipelines-tasks-kubernetes-common-v2/module.json
==============================================================================
			Kubectl Client Version: v1.19.0
			Kubectl Server Version: v1.18.10
==============================================================================

Task logs
Logs above

This is a warning. It wouldn't impact your release in any way. It's probably a side effect of us upgrading the underlying task-lib version to 3.0.6-preview.
@shigupt202 could you take a look?

This is a warning. It wouldn't impact your release in any way. It's probably a side effect of us upgrading the underlying task-lib version to 3.0.6-preview.
@shigupt202 could you take a look?

This is happening probably because KubernetesV1 is dependent on azure-pipelines-tasks-azure-arm-rest-v2 which has the an older version of azure-pipelines-task-lib, while we have specified the latest version in it's package.json. This should not have any effect on the pipeline run.
@ds-ms Any suggestion what we should do here? Should we downgrade the task-lib version of this task, or ask the owners to update azure-pipelines-tasks-azure-arm-rest-v2?

This is happening probably because KubernetesV1 is dependent on azure-pipelines-tasks-azure-arm-rest-v2 which has the an older version of azure-pipelines-task-lib, while we have specified the latest version in it's package.json. This should not have any effect on the pipeline run.
@ds-ms Any suggestion what we should do here? Should we downgrade the task-lib version of this task, or ask the owners to update azure-pipelines-tasks-azure-arm-rest-v2?

authors: ds-ms sadedil shigupt202

repo: microsoft/azure-pipelines-tasks


text:
[BUG]: Unable to copy files to Azure with an Azure Service Connection bound to Management Group

Task name
AzureFileCopy
Task version
1
Environment type (Please select at least one enviroment where you face this issue)

[ ] Self-Hosted
[X] Microsoft Hosted
[ ] VMSS Pool
[ ] Container

Azure DevOps Server type
dev.azure.com (formerly visualstudio.com)
Azure DevOps Server Version (if applicable)
No response
Operation system
N/A
Task log
No logs yet.
I have an error when I trying to configure the task in the UI:
Failed to query service connection API: 'https://management.azure.com/subscriptions/providers/Microsoft.Storage/storageAccounts?api-version=2015-06-15'. Status Code: 'BadRequest', Response from server: '{"error":{"code":"InvalidSubscriptionId","message":"The provided subscription identifier 'providers' is malformed or invalid."}}'

Relevant log output
Failed to query service connection API: 'https://management.azure.com/subscriptions/providers/Microsoft.Storage/storageAccounts?api-version=2015-06-15'. Status Code: 'BadRequest', Response from server: '{"error":{"code":"InvalidSubscriptionId","message":"The provided subscription identifier 'providers' is malformed or invalid."}}'

Aditional info
Similar to #19112, this task does not offer an optional subscription Id for Azure service Connection bound to a Management Group.

Similar to #19112

Hi,
I know there is no activity for a long time on this bug, but it is not a reason to close: it should be a reason to work on it...

Hi,
I know there is no activity for a long time on this bug, but it is not a reason to close: it should be a reason to work on it...


text:
NuGet Push fails when TLS 1.0 is disabled

Environment

Azure Pipelines

Account: Emdat
Team Project: Emdat
Build Definition: InScribe

Private Agent

OS: Windows Server 2016
Agent Version: 2.140.0

Issue Description
Nuget Push fails if you disable TLS 1.0

HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client

DisableByDefault = 1
Enabled = 0

Task logs
NuGetPushFailedLog.zip
Error logs
Error: An unexpected error occurred while trying to push the package with VstsNuGetPush.exe. Exit code(1) and error(Error:
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)
at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]& output)
at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback asyncCallback, Object asyncState)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d__47.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at VstsNuGetPush.NuGetServiceIndexHttpClient.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at VstsNuGetPush.HttpServiceIndexProvider.b__3_0(VssClientCredentials credentials)
at VstsNuGetPush.CredentialSelector.TrySelectCredential[TResult](Func2 func, IVssCredentialStorage vssClientCredentialStorage, CredentialPromptType promptType, TResult& result)    at VstsNuGetPush.CredentialSelector.Select[TResult](Func2 func)
at VstsNuGetPush.Patterns.Helpers.FactoryAdaptorChain2.Get()    at System.Lazy1.CreateValue()
at System.Lazy`1.LazyInitValue()
at VstsNuGetPush.VstsNuGetPushCommand.MainCore(ILogger logger)
at VstsNuGetPush.VstsNuGetPushCommand.Main())
1 more errors. Click on expand view in the context menu to view complete logs.

Hi @efelito , sorry for the delay here. Just making sure you're still seeing this issue?

Hi @efelito , I haven't heard back, and we're also making some key changes to our tasks this quarter, those changes should make this issue obsolete so I'm going to close this one.

authors: efelito elbatk


text:
Multi-Stage YAML - Deployment variable uses latest value not snapshot during rerun the stage

In the classic release pipeline when you redeploy the existing release, pipelines will make use of the same variables that were used when the release was initially created. In the multi-stage pipeline, I am seeing the value is picked freshly/newly even when we rerun the existing deployed stage.
It's a breaking change in the behavior between classic release pipeline vs YAML pipeline.
Expected: Use the same variable value which was used in the initial run rather than using the updated value.
Scenario:
First time I ran with value “Value1” in the Azure DevOps Variable group and the task printed “Value1” in the pipeline.
All good here.
Now what I do here is update the value in the Azure DevOps variable group for the variable “Test” to “Value2”. To be more clear it’s updated only in the library variable group.
Now I am not running any new deployment or run the pipeline. I am trying to run the previous deployment using “Rerun stage” as shown in the below screenshot. Effectively Redeploying the previous deployment here.
Now I expected since it’s rerun it should print in the pipeline as “Value1” rather “Value2”. But it’s printing as “Value2” which shouldn’t be.
Because what happens is after a month of deployment “Release1” I might have done a new release to the environment “Release 2” but something went wrong I want to effectively deploy the last successful deployment with the same old variable values not picking the latest.
I already raised in the developer community the below issue and it's reported as a limitation (works as designed)
https://developercommunity2.visualstudio.com/t/multi-stage-deployment-variable-value-overrides-du/1309176?from=email&viewtype=all#T-ND1309772

That is pretty danger. If you can not rely on repeating things when rerunning but do something completely different.
I am also heavily relying of such behaviour.

That is really danger if you can not rely on reproducible results repeating things. Please fix this

Hoping the issue gets resolved earliest. With this behavior, we can't use the YAML pipeline in production scenarios.

Hi @rajurh this repo is mostly for yaml templates - your question is more related to DevOps Server side, I would suggest to ask any further questions on https://developercommunity2.visualstudio.com/search?from=email&viewtype=all&space=21 to get right eyes on it.
Closing this here since it's not related to yaml templates.

I'm here looking for an answer to this question, seeing the same thing.
It got closed down but searches for yaml snapshot variables not working brings one to here.
Any clues

authors: anatolybolshakov cforce jonathh21 rajurh

repo: microsoft/azure-pipelines-yaml


text:
When doing a commit in resource control, it keeps on spinning and never ands

Azure Data Studio Version: 1.44
OS Version: Windows 10

Steps to Reproduce:

I create a branch from the master branch
I make some adjustments, in this branch, in this case i addes a stored procedure.
I press on Commit. Then it keeps on spinning.

I allready closed the program, restarted the programm, cloned the repository again and uninstalled and installed data studio again, but without positive result.

Does this issue occur when all extensions are disabled?: Yes/No yes (i don't use extensions

@mcronaldp I wasn't able to repo this locally.  Are you seeing any errors in the "Help->Developer Tools" Console log?  Also, it may be helpful to confirm (1) you can successfully commit to the repo using CLI git tools (e.g. git commit) and (2) that this scenario works in VS Code, to help isolate if this is upstream issue or not.  Thanks!

Closing as inactive, please re-open if you have more details to provide and it still happens.

authors: cheenamalhotra kburtram mcronaldp

repo: microsoft/azuredatastudio


text:
Remove config update from subscription filter

Fixes #10438
Not exactly sure why this has just recently started appearing - my best initial guess though is that the Tree used to display the Azure accounts was updated in a recent VS Code merge to cause these to be surfaced. This code has always been broken as far as I can tell from its original implementation (we never were setting the config) and the error itself is also nothing new.
We might want to relook at how we're storing this since currently it's tied to the workspace - but this fix at least gets rid of the error and isn't going to change any existing behavior.

Coverage increased (+0.01%) to 33.975% when pulling e9af5cd817878ff9dbf9564214c2139d126999e0 on chgagnon/fixSubFilterError into 452bd6a0cb3336cb5b4e05cd5d6f13a3ba47719c on master.

authors: Charles-Gagnon coveralls


text:
fix accessibility issue

https://msdata.visualstudio.com/Database Systems/_workitems/edit/1276698
fix: apply the styles first before showing the dialog.
before:

after:

Pull Request Test Coverage Report for Build 1106542157

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.007%) to 41.719%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/browser/modal/optionsDialog.ts
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/sql/workbench/browser/modal/optionsDialog.ts
1
9.09%

Totals

Change from base Build 1106513606:
0.007%

Covered Lines:
26424

Relevant Lines:
57474

💛  - Coveralls

authors: alanrenmsft coveralls


text:
Add AAD token refresh to object explorer

This PR is a partial fix for #17087 which adds a refreshSessionIfNecessary call before provider expand/refresh node.
Note that OE doesn't create server connection via connection management service so in ADS we don't have the uri to connection mapping stored. This makes it difficult to reuse the refreshAzureAccountTokenIfNecessary from CMS. There are multiple gaps to fill on both ADS and STS side if we take this approach.
I chose to check the connection expiry info stored in session status. Once a token is expired, OE will just close the previous session and create a new session using a refreshed token. This way we can avoid updating session map and blinding context in STS.
This change does NOT re-construct the previously expanded nodes if a refresh happens, so users will only see nodes like Databases and Security not their children.
Screenshots of expanding/refreshing a node in an expired OE session:
Before
#TO-BE-ADDED
After:

Pull Request Test Coverage Report for Build 1271537792

13 of 22 (59.09%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 41.66%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/services/objectExplorer/browser/objectExplorerService.ts
13
22
59.09%

Totals

Change from base Build 1271493467:
0.008%

Covered Lines:
26588

Relevant Lines:
57828

💛  - Coveralls

@caohai  are you still planning anything with this PR?  or should we close it out as part of stale PR cleanup?  It looks like CI builds are failing and PR is still in draft, so we'd want to fix that prior to merging if still needed.  Thanks!

@caohai are you still planning anything with this PR? or should we close it out as part of stale PR cleanup? It looks like CI builds are failing and PR is still in draft, so we'd want to fix that prior to merging if still needed. Thanks!

I believe we discussed about this PR a while back and came to the conclusion that recreating the session (as I implemented in this PR) in ADS is not the ideal approach and refreshing the token on STS side is favored. I didn't get a chance to look into the later approach after that.
I'll close this PR for now and probably revisit this issue with the committer time later.

authors: caohai coveralls kburtram


text:
Update Extension to Use New Monitoring Data API

This PR fixes #
Update getMonitoringData api in the ads extension.:
Details:
(Note - Old API is still active, so this does not break ADS)
GetMonitoringData API has changed:
Before:
https://localhost:6363/modules/ArmSqlMigration/subscriptions/0009fc4d-e310-4e40-8e63-c48a23e9cdc1/resourceGroups/azrRG/providers/Microsoft.DataMigration/sqlMigrationServices/azrTest2/ MonitoringData?api-version=2020-09-01-preview&details=monitoringdata
After:
https://localhost:6363/modules/ArmSqlMigration/subscriptions/0009fc4d-e310-4e40-8e63-c48a23e9cdc1/resourceGroups/azrRG/providers/Microsoft.DataMigration/sqlMigrationServices/azrTest2/ getMonitoringData?api-version=2020-09-01-preview&details=monitoringdata

@brian-harris @stuti149 Are you still planning on getting this in?


text:
[SKU Recommendation] Adding telemetry for errors happening during data collection/ get  recommendation and telemetry

This change is important to understand what kind of errors are happening during data collection/ recommendation/ telemetry. This will help us improve our feature.

Pull Request Test Coverage Report for Build 1839115163

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.005%) to 48.239%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/book/bookTreeView.ts
2
38.21%

Totals

Change from base Build 1832864975:
-0.005%

Covered Lines:
14799

Relevant Lines:
29109

💛  - Coveralls

authors: coveralls neetusingh-ms


text:
[Loc] sql-bindings xlf update

This PR fixes #

Pull Request Test Coverage Report for Build 2625551854

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.003%) to 42.386%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/jupyter/pypiClient.ts
1
81.82%

extensions/sql-database-projects/src/dialogs/publishDatabaseDialog.ts
2
51.89%

Totals

Change from base Build 2625507551:
-0.003%

Covered Lines:
28403

Relevant Lines:
62522

💛  - Coveralls

authors: coveralls smartguest


text:
Revert "systemd: add Provides: for the "bootstrap" package names"

This reverts commit e2f7ca6f2f705b2447aa3e98f6ef8bf76ec6f08f.
This commit exposes a limitation in our build-cycle resolution code. Will need to fix it, but revert in the meantime.
We should not have been able to publish this package as-is, so I believe the revert of the release number is ok.
Bug: https://microsoft.visualstudio.com/OS/_workitems/edit/49601294
Build: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=533021&view=results

I won't make any comment on what the toolkit needs or how to fix it, but keep in mind that package upgrades to the entire systemd package WILL BE BROKEN until this revert is unreverted. The systemd rpm macros MUST be available when building systemd.

I won't make any comment on what the toolkit needs or how to fix it, but keep in mind that package upgrades to all the systemd packages WILL BE BROKEN until this revert is unreverted. The systemd rpm macros MUST be available when building systemd.

oh sorry I thought you were reverting #8471? The bug referenced that PR, not #8467?
Reverting #8467 is simply annoying, so that's fine (but disappointing that the toolkit can't handle it). If that's really all the toolkit needs to unbreak itself.

authors: ddstreetmicrosoft dmcilvaney

repo: microsoft/azurelinux


text:
break createPullRequest function in lib/git/azure.ts into smaller and testable parts

As a:
Developer
I want:
I have to have smaller and testable functions
So that:
code can be tested and reduce software defects
Describe the solution you'd like:
break big function https://github.com/CatalystCode/spk/blob/master/src/lib/git/azure.ts#L108 into small parts and add tests
Acceptance Criteria:
functions are less than 30 lines and code coverage is over 90%
Describe alternatives you've considered:
Additional context:
Does this require updates to documentation?:
no

@dennisseah this belongs in sprint 12

authors: bnookala dennisseah

repo: microsoft/bedrock


text:
fix & refactor: REST samples endpoints update + load_dotenv usage

PR Classification
This pull request updates REST code samples (including endpoints) and improves robustness by using default values and clear error messages and supporting .env file for secrets.
PR Summary

Environment variables are now loaded from the .env file using the dotenv package across all scripts.
.gitignore has been updated to exclude the .env file, preventing accidental commits of sensitive data.
The endpoint variable now has a default value depending on the service.
subscription_key variable is fetched strictly from environment variables and throws a clear error message when it fails to load.
Minor improvements:

Entity Search query changed to accommodate latest changes.
Spell Check now uses the better POST method instead of GET.

Please feel free to ignore, @hario90.

Great job @GhiathAjam! ✨ My only take is that we might need to configure some formatting for the python source code in order to avoid changes like single and double quotes for string literals and spacing on variable assignments, like
API_KEY='BING_SEARCH_V7_AUTO_SUGGEST_SUBSCRIPTION_KEY'
# versus
API_KEY = 'BING_SEARCH_V7_AUTO_SUGGEST_SUBSCRIPTION_KEY'

Thanks Kerollos, that was actually discussed along with other changes and decided to be on a later PR.

[celebrate]     Gheiath Ajam (International Bu... reacted to your message:

From: Kerollos Magdy @.>
Sent: Thursday, June 6, 2024 9:20:13 AM
To: microsoft/bing-search-sdk-for-python @.>
Cc: Gheiath Ajam (International Business Service) @.>; Mention @.>
Subject: Re: [microsoft/bing-search-sdk-for-python] fix & refactor: REST samples endpoints update + load_dotenv usage (PR #14)
@kerolloz approved this pull request.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/bing-search-sdk-for-python/pull/14#pullrequestreview-2101386272, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKI5K7I7SGD3F77F7GWH333ZGASU3AVCNFSM6AAAAABI3G4QX6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCMBRGM4DMMRXGI.
You are receiving this because you were mentioned.Message ID: @.***>

@arwong @nader-m-elhadedy  Please re-review and resolve fixed issues. Thanks.

@GhiathAjam Yes, I guessed so, and you are 100% right.
I don't know if this is the case or not, but you can have some util functions, which are totally customized, and only import them in the samples provided. Again, you know better than me.

authors: GhiathAjam Mohammed-Deifallah

repo: microsoft/bing-search-sdk-for-python


text:
add source location property to dialogs and triggers

this allows you to inspect object in debugger and see where it came from

Pull Request Test Coverage Report for Build 92092

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-1.0%) to 75.561%

Files with Coverage Reduction
New Missed Lines
%

/libraries/Microsoft.Bot.Builder.Dialogs/Debugging/SourcePoint.cs
1
86.67%

/libraries/Microsoft.Bot.Builder.Dialogs/Dialog.cs
5
91.04%

Totals

Change from base Build 92082:
-1.0%

Covered Lines:
8215

Relevant Lines:
10872

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.ApplicationInsights.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Testing.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Streaming.dll compared against version 4.6.3

authors: coveralls fuselabs tomlm

repo: microsoft/botbuilder-dotnet


text:
Remove the patch install from ExtractCompressNuGet.ps1

Same as PR #4896 for main branch.

Wrong files!


text:
Change the implementation in string a number in the string pre-built function

Currently, the string pre-built function does not always work correctly for numeric inputs.
for example: string(1.22, 'de-DE') returns 1.22. It is not the same as the result of C#.
So I switched the toLocaleString() to d3-format in the string function while a numeric input passed.
With the change, now string(1.22, 'de-DE') will return: 1,22

Pull Request Test Coverage Report for Build 527193603

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.009%) to 84.673%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

libraries/adaptive-expressions/src/builtinFunctions/string.ts
2
84.78%

Totals

Change from base Build 526439639:
-0.009%

Covered Lines:
18204

Relevant Lines:
20512

💛  - Coveralls

authors: cosmicshuai coveralls

repo: microsoft/botbuilder-js


text:
Add double quote to autoClosingPairs

This PR adds double quote to the autoClosingPairs for the Cadl language server.
Fixes #1417

Re-queued this since the playground failed. That comment dates back to the very first day I played with setting up IDE support for Cadl a long time ago. I don't think I expected it to last this long. 😳 There are other languages have " and """ so I assume there is something we can do. I'll take a quick look to see if they do something smart and if it's easy to steal.

Hmm, publish to playground is still failing and I was eager to try it.
@timotheeguerin Any ideas?

Looking for comments in { repo: 'microsoft/cadl', prNumber: '1447' }
Params {
  method: 'GET',
  host: 'api.github.com',
  port: 443,
  path: '/repos/microsoft/cadl/issues/1447/comments',
  headers: { 'User-Agent': 'nodejs' }
}
Found 0 comment(s) from Azure Pipelines.
Found 0 Cadl Try It comment(s)
Params {
  method: 'POST',
  host: 'api.github.com',
  port: 443,
  path: '/repos/microsoft/cadl/issues/1447/comments',
  headers: { 'User-Agent': 'nodejs', 'Content-Type': 'application/json' }
}
Error: Status Code: 403
    at ClientRequest.<anonymous> (file:///mnt/vss/_work/1/s/eng/scripts/create-tryit-comment.js:98:23)

I have seen it fail with those 403 but it doesn't seem to be all the time

OK requeued 🤞

/azp run

/cadl run Cadl Pull Request Try It

authors: mikekistler nguerrera timotheeguerin

repo: microsoft/cadl


text:
Automated UI Tests for the Programmer Calculator Mode

Problem Statement
Currently, the basic smoke tests for Programmer calculator mode are all manual.  There aren't any automated UI tests for calculator modes other than the standard calculator mode.  Automation testing is faster than manual testing. Repeated test that can be automated, should be automated.
Evidence or User Insights
It would be helpful to developers and testers to have some streamlined, reliable UI tests for the Programmer calculator mode.
Proposal

These tests would allow developers to know that their feature/code change, when introduced to the application, does not break other aspects of the application.
These tests allow testers to focus on more creative, testing scenarios during manual testing rather than spending a lot of extra time executing tests that an automaton could complete.

Goals

Replace basic, repeatable manual tests, with streamlined, reliable automated UI tests for the Programmer calculator mode
Use these tests as a gate when checking in new features

Non-Goals

The UI automated tests are not a replacement for Unit tests
The UI automated tests will not cover end-to-end testing (It will cover smoke/BVT type tests)

Low-Fidelity Concept
Read through "ManualTests.md" (https://github.com/microsoft/calculator/blob/master/docs/ManualTests.md).  Would you prefer to execute these tests manually, or if possible, execute most of these through automation?
Requested Assignment
If possible, I would like to implement this.

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

cc: @sanderl

Marking this as complete since #779 was merged. We'll track further improvements in this area as separate issues.

authors: MicrosoftIssueBot grochocki mcooley v-credwa

repo: microsoft/calculator


text:
Rust Analyzer can't recognize the IUnknown

It's very hard to develop on 0.3 since Rust Analyzer can't recognize the IUnknown.
In VSCode settings.json I have this:
{
    "rust-analyzer.procMacro.enable": true
}

And if I write this:
use com::{interfaces, interfaces::iunknown::IUnknown};

fn main() {
    println!("Hello, world!");
}

It gives unresolved import:

Yet it builds just fine with cargo build.
I think RLS support is a must, developing without IDE support is pretty difficult, maybe I have misconfigured my setup somehow.
Also from the get-go, I think I don't like the macro approach in 0.3, because I suspect it will break Go to definition etc. IDE features that used to work with trait approach.

I've also raised this in Rust Analyzer forums: https://users.rust-lang.org/t/proc-macros-does-not-work-with-com-crate/53731
I can't understand how one can program without intellisense :) I need to get this working.

I've also raised this in Rust Analyzer forums: https://users.rust-lang.org/t/proc-macros-does-not-work-with-com-crate/53731
I can't understand how one can program without intellisense :) I need to get this working.

@ciantic Afaik this has been working fine in the past, but even going back to rust-analyzer 2020-10-05 shows the same issue. Oddly enough jump-to-symbol works in the webview2 example.
Note that IUnknown is a plain struct here that's not wrapped/generated by proc-macro...

@ciantic Afaik this has been working fine in the past, but even going back to rust-analyzer 2020-10-05 shows the same issue. Oddly enough jump-to-symbol works in the webview2 example.
Note that IUnknown is a plain struct here that's not wrapped/generated by proc-macro...

This was also raised here on Zulip. You'll need to enable both "Load out dirs from check" and "Enable proc macro support".

This was also raised here on Zulip. You'll need to enable both "Load out dirs from check" and "Enable proc macro support".

Uh, looks like my Zulip thing has gone forward more, someone opened an issue https://github.com/rust-analyzer/rust-analyzer/pull/7171

Uh, looks like my Zulip thing has gone forward more, someone opened an issue https://github.com/rust-analyzer/rust-analyzer/pull/7171

Edit I see you managed to repro this with all the way to 2020-10-05? Well something is broken in analyzer in that case.

@Ciantic  Yup. Could have been (way) longer since I last actively developed on a crate with com-rs though.
Rebuilt RA at https://github.com/rust-analyzer/rust-analyzer/commit/861a547 (includes that PR), doesn't solve it (don't think it was intended to, but I have not read into the PR/Zulip yet).

Edit I see you managed to repro this with all the way to 2020-10-05? Well something is broken in analyzer in that case.

@Ciantic  Yup. Could have been (way) longer since I last actively developed on a crate with com-rs though.
Rebuilt RA at https://github.com/rust-analyzer/rust-analyzer/commit/861a547 (includes that PR), doesn't solve it (don't think it was intended to, but I have not read into the PR/Zulip yet).

authors: Ciantic MarijnS95 rylev

repo: microsoft/com-rs


text:
New lab for Graph Connector in Trey Genie

Write a bonus track to Lab path E using Bob's E3 sample DA with a separate downloadable artifact sample of a GC sample with Consulting scenario

source code added for Trey Genie updated with GC and also source code for GC https://github.com/microsoft/copilot-camp/tree/main/src/extend-m365-copilot/path-e-bonus-gc-lab @BobGerman

https://microsoft.github.io/copilot-camp/pages/extend-m365-copilot/EB-add-graphconnector/

repo: microsoft/copilot-camp


text:
Use unityhub package instead of Unity 2020

Suggested new feature or improvement
In the recommended apps section use the unity.unityhub package and not unity.unity.2020.
Scenario
From the hub you can install a diverse set of versions and devhome doesn't need to adapt when a newer version releases.
Additional details
No response

Take a look at:

#375

authors: Aaron-Junker denelon

repo: microsoft/devhome


text:
adding seesaw bare library

Basic Adafruit Seesaw library. Needs hardware testing.

will be moved to a separate project

repo: microsoft/devicescript


text:
Configure Blob Format for Functions

Description
Now that Azure Functions may read blob data for Export, it also needs to know which blob format to use. Furthermore,  re-indexing used to simply log whether it could not find a metadata blob because a missing blob meant the entry was deleted sometime between the beginning of re-indexing and now. However, this assumption is incorrect once we introduced a new blob format. Erroneously, the re-index orchestration is ignoring instances whose metadata cannot be found thinking it is because they were deleted when in actuality it is because the blob path changed.

Add blob migration configuration to functions project
Make "New" the default blob format
Update ErrorHref to export input for quality-of-life. Now the operation status can immediately return the complete set of data
Use lowercase in export paths
Refactor re-indexing missing blob handling to double-check the blob was truly deleted

Related issues
N/A
Testing
Tests now use new blob format

We need to leave the default blob format as Old for the time being since that is the default behavior in the project - we have communicated plans to move to the new format in a future version but we need to clarify the migration path first.

I've changed the default parameter for the ARM template to use the old format.

Now that Azure Functions may read blob data for Export, it also needs to know which blob format to use. Furthermore, re-indexing used to simply log whether it could not find a metadata blob because a missing blob meant the entry was deleted sometime between the beginning of re-indexing and now. However, this assumption is incorrect once we introduced a new blob format. Erroneously, the re-index orchestration is ignoring instances whose metadata cannot be found thinking it is because they were deleted when in actuality it is because the blob path changed.

Add blob migration configuration to functions project
Make "New" the default blob format for tests
Update ErrorHref to export input for quality-of-life. Now the operation status can immediately return the complete set of data
Use lowercase in export paths
Refactor re-indexing missing blob handling to double-check the blob was truly deleted

repo: microsoft/dicom-server


text:
Move to new api

Create an API than can run third-party estimators

Thanks @Tanmay-Kulkarni101 . This is good enough to pull in. But we'll need to think about meaningful error messages in case a user passes an incorrect string. That can be a later addition.

repo: microsoft/dowhy

license: mit

license_source: bigquery


text:
ebpf-for-windows should serialize data passed across security boundaries

Data that is exchanged between EC and PPL process should use serialization to enforce type safety and correctness.
Proposed serialization engines are:

RPC - Use RPC serialization services
protobuf/protobuf-c - Use ProtocolBuffer or ProtocolBuffer for c

Option 1 would be preferred due to familiarity, but it looks like the public DDK can't call msrpc.sys.
Option 2 should work, but we need to use the c port for kernel mode due to lack of support for conformant C++ new in the kernel (lack of support for C++ exceptions means new returns nullptr instead of throwing std::bad_alloc).

@shankarseal can you common on whether this issue was fixed by #302?

@shankarseal can you common on whether this issue was fixed by #302?

Yes I think we can resolve this against #302 .

Closing per Shankar's note above.  Please reopen if you disagree.

authors: Alan-Jowett dthaler shankarseal

repo: microsoft/ebpf-for-windows


text:
libfuzzer based fuzzer's aren't covering all code paths

Launch execution context fuzzer under debugger.
Place breakpoints on all protocol handler functions.
As each function is hit, remove that breakpoint.

Expected result:
All protocol handles should be hit at least once.
Actual result:
The following were never hit:
execution_context_fuzzer!_ebpf_core_protocol_map_update_element_with_handle
execution_context_fuzzer!_ebpf_core_protocol_ring_buffer_map_query_buffer
execution_context_fuzzer!_ebpf_core_protocol_create_program
execution_context_fuzzer!_ebpf_core_protocol_load_code
execution_context_fuzzer!_ebpf_core_protocol_map_get_next_key_value_batch
execution_context_fuzzer!_ebpf_core_protocol_get_pinned_object
execution_context_fuzzer!_ebpf_core_protocol_get_pinned_map_info
execution_context_fuzzer!_ebpf_core_protocol_create_map
execution_context_fuzzer!_ebpf_core_protocol_get_program_handle_by_id
execution_context_fuzzer!_ebpf_core_protocol_link_program
execution_context_fuzzer!_ebpf_core_protocol_close_handle
execution_context_fuzzer!_ebpf_core_protocol_map_delete_element
execution_context_fuzzer!_ebpf_core_protocol_map_update_element
execution_context_fuzzer!_ebpf_core_protocol_convert_pinning_entries_to_map_info_array
execution_context_fuzzer!_ebpf_core_protocol_get_link_handle_by_id
execution_context_fuzzer!_ebpf_core_protocol_unlink_program
execution_context_fuzzer!_ebpf_core_protocol_get_map_handle_by_id
execution_context_fuzzer!_ebpf_core_protocol_map_update_element_batch
execution_context_fuzzer!_ebpf_core_protocol_map_delete_element_batch
execution_context_fuzzer!_ebpf_core_protocol_load_native_module
execution_context_fuzzer!_ebpf_core_protocol_serialize_map_info_reply
execution_context_fuzzer!_ebpf_core_protocol_bind_map
execution_context_fuzzer!_ebpf_core_protocol_get_ec_function

Since libfuzzer sets the reply buffer size to random value, it misses all the protocol messages that require a specific size.

authors: Alan-Jowett shankarseal


text:
TabLayout requires explicitly calling updateTemplate()

When inflating Fluent's TabLayout component via a Fragment's XML , it requires explicitly calling TabLayout.updateTemplate() to render correctly.
In an Activity or Adapter, the TabLayout component does not require explicitly calling this function, so I believe it is a bug.
See example before/after picture below:

Before calling updateTemplate()
After calling updateTemplate()

The need to explicitly call updateTemplate() in a Fragment's XML but not in an Activity or Adapter is likely due to the lifecycle differences between these components. Here are some potential reasons:
Fragment Lifecycle: Fragments have a more complex lifecycle compared to Activities. The onAttachedToWindow() method, where updateTemplate() is called, might not be triggered at the same time or in the same way for Fragments as it is for Activities. This can result in the TabLayout not being fully initialized when the Fragment's view is created.
View Hierarchy: When inflating views in a Fragment, the view hierarchy might not be fully established, causing certain methods like onAttachedToWindow() to not be called as expected. This can prevent updateTemplate() from being invoked automatically.
Delayed Initialization: In Fragments, views might be initialized or attached to the window later than in Activities or Adapters. This delay can cause the TabLayout to miss the automatic call to updateTemplate().
Closing this issue for now. Feel free to reopen if there are any further questions on this.
Thanks!

repo: microsoft/fluentui-android


text:
Exclude swiftsourceinfo files from nuget

Platforms Impacted

[x] iOS
[x] macOS

Description of changes
When trying to consume an Xcode 12.5 prebuilt version of Fluent UI Apple in Xcode 13 beta, you get a warning that the source info for the module might be corrupted. If you have warnings turned on as errors, this will cause a build break in the Xcode 13 beta project trying to consume Fluent UI Apple.
However, Xcode only tries to load the swift source info files if they are present. Let's just remove them from the prebuit NuGet binaries as we don't require them.
Note: This impacts Microsoft's internal consumption of Fluent UI Apple only.
Verification
Run the scripts/publish_nuget.sh script before and after the change and diff the

Before
After

Pull request checklist
This PR has considered:

[ ] Light and Dark appearances
[ ] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[ ] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)

Microsoft Reviewers: Open in CodeFlow

for my own knowledge, "swift source info files" what are these for? any impact on existing flow?

for my own knowledge, "swift source info files" what are these for? any impact on existing flow?

swiftsourceinfo files are essentially local file path mappings for symbols. They're useful if everything is built on the same machine to help provide better diagnostics and cross-module fixits.
Since in our particular case the compilation is happening on a different machine than those consuming the built outputs, this doesn't provide us any benefit.

authors: harrieshin markavitale

repo: microsoft/fluentui-apple


text:
fix: navmenu error in v4 template for automode

🐛 Bug Report
The new v4 WebApp Template throws an error in the console when using automode and it has switched to WASM.

🤔 Expected Behavior
NavMenu should continue to work in WASM mode
💁 Possible Solution
Move the NavMenu component to the Client project

What did you specify for the interactivity location? Per page or Global. The template only moves the layout items to the Client project when Global is selected

It was set to per page

I guess I was thinking that since the nav menu contains interactivity in the template, then it would be placed where it will always work based on the project parameters.

repo: microsoft/fluentui-blazor


text:
Implement 1ES pipeline templates; migrate off Arcade

For https://github.com/microsoft/go-lab/issues/52

Split into two commits. The second is entirely deletions. I have a commit prepared for a followup PR to remove the now-unused Arcade content.
Broad approach:

Remove the Arcade dependency to simplify migration.

Use MicroBuild for signing directly rather than going through an Arcade package. The MSBuild flow is mostly unchanged, we just use MicroBuild directly rather than through the Arcade SignTool.
Use 1ES PT for SDL (scans, CodeQL, etc.). Remove existing validation-specific pipeline yml that used Arcade.
Removed auto-build-retention script for now. Filed for followup: https://github.com/microsoft/go-lab/issues/59.

Split the official build into production and non-production:

Rolling internal build now only builds.

It doesn't use our containers anymore because they don't support 1ES PT.
It now builds the arm64 Go on an amd64 host, because this was more expedient than trying to get an arm64 host that complies with 1ES PT requirements.
Risk: will the glibc version be too new for some of our users? (TODO: https://github.com/microsoft/go-lab/issues/60)

New internal innerloop pipeline runs tests.

Doesn't use 1ES PT, because it isn't a production pipeline.
Runs tests inside containers, and tests that buildandpack works on an arm64 host.

This could catch problems with building our Go in the Azure Linux arm64 distro, although in general problems here don't seem likely to happen.

Test internal builds:

Official: https://dev.azure.com/dnceng/internal/_build/results?buildId=2404993&view=results
Innerloop: https://dev.azure.com/dnceng/internal/_build/results?buildId=2403407&view=results

Based on this test build:
https://dev.azure.com/dnceng/internal/_build/results?buildId=2405912&view=results (e4faa2cfc493ce6da303563f3c56b6f9af605efb)
This release build test run successfully made aka.ms links using the build asset JSON: https://dev.azure.com/dnceng/internal/_build/results?buildId=2405995&view=results
A build is in progress to validate the last few fixups:
https://dev.azure.com/dnceng/internal/_build/results?buildId=2405994&view=results

repo: microsoft/go


text:
ENH: Improve Amulet support and documentation

Merging #612 from main

opened by accident

repo: microsoft/hi-ml


text:
Fix to win installation

Closes #166 and #177.
This PR

pins the version for PyTorch to 1.4.0 (version >=1.5.0 introduce 10X performance regression)
fix installation for Windows

Codecov Report

Merging #179 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #179   +/-   ##
=======================================
  Coverage   93.57%   93.57%
=======================================
  Files          25       25
  Lines        1573     1573
  Branches      290      290
=======================================
  Hits         1472     1472
  Misses         60       60
  Partials       41       41

Flag
Coverage Δ

#unittests
93.57% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 40d8cc9...a2772d9. Read the comment docs.

authors: codecov-commenter interesaaat

repo: microsoft/hummingbird


text:
basePath in Swagger specifications does not appear to be treated correctly

I have a Swagger YAML specification that looks like this (paraphrased):
basePath: "/foo"
paths:
    /bar:

When I generate from this specification, the client contains the following:
public MySwaggerClient(IRequestAdapter requestAdapter) : base(requestAdapter, "{+baseurl}", new Dictionary<string, object>())
{
    ApiClientBuilder.RegisterDefaultSerializer<JsonSerializationWriterFactory>();
    ApiClientBuilder.RegisterDefaultSerializer<TextSerializationWriterFactory>();
    ApiClientBuilder.RegisterDefaultSerializer<FormSerializationWriterFactory>();
    ApiClientBuilder.RegisterDefaultSerializer<MultipartSerializationWriterFactory>();
    ApiClientBuilder.RegisterDefaultDeserializer<JsonParseNodeFactory>();
    ApiClientBuilder.RegisterDefaultDeserializer<TextParseNodeFactory>();
    ApiClientBuilder.RegisterDefaultDeserializer<FormParseNodeFactory>();
    if (string.IsNullOrEmpty(RequestAdapter.BaseUrl))
    {
        RequestAdapter.BaseUrl = "https:///foo";
    }
    PathParameters.TryAdd("baseurl", RequestAdapter.BaseUrl);
}

and the request builder contains:
public BarRequestBuilder(string rawUrl, IRequestAdapter requestAdapter) : base(requestAdapter, "{+baseurl}/bar", rawUrl)
{
}

This seems incorrect: the client appears to be conflating base path with base URL, which are by no means the same thing, with the result that if the provided request adapter already has a base URL, the base path is never applied, the absolute URL is resolved incorrectly, and the API call fails. To my mind the correct behaviour is that if a basePath is provided, it should be prepended to the urlTemplate in every generated request builder, e.g.:
public BarRequestBuilder(string rawUrl, IRequestAdapter requestAdapter) : base(requestAdapter, "{+baseurl}/foo/bar", rawUrl)
{
}

There is also no need for the following block in the client constructor:
    if (string.IsNullOrEmpty(RequestAdapter.BaseUrl))
    {
        RequestAdapter.BaseUrl = "https:///foo";
    }
    PathParameters.TryAdd("baseurl", RequestAdapter.BaseUrl);

Thanks for raising this @IanKemp
Any chance you can share a sample openApi description that you used to replicate this?
Ideally, the OpenApi.Net library used to parse the description should append the basePath component to the server string to ensure the baseUrl is correct.
https://github.com/microsoft/OpenAPI.NET/blob/29b1a1a9acbc65d7b2961b3f08e681a1e59d7c38/src/Microsoft.OpenApi.Readers/V2/OpenApiDocumentDeserializer.cs#L138

authors: IanKemp andrueastman

repo: microsoft/kiota


text:
Example Usage code doesn't work

Example Usage code doesn't work.
If this code is compiled, An compile error which points out no argument for a method named hexdump is occurred.

I think the argument expected for hexdump is &serialized_data.

Yeah, it should be &serialized_data. Looks like I made a copy/paste error. Thanks for pointing this out, I'll fix it soon.

repo: microsoft/lain


text:
Improve cpu online offline cases.

Once allocate cpu 0 for all channels, then take cpu offline/online on remain cpus.
Minor fix for install fio and ethtool.

@LiliDeng does it need any more?

authors: LiliDeng squirrelsc

repo: microsoft/lisa


text:
Debian 13 Arm16 testing

…gives "trixie/sid" which throws Assertion Error. Hardcoding the version value to "13.0" to run the tests

@rabdulfaizy What's this PR for? It just hard code a version. Please close the PR, until it's ready for reviewing or preview.

@rabdulfaizy I gave you write permission of this repo. please create test branches, not PRs.

[like]  Raheel Abdul Faizy reacted to your message:

From: Chi Song @.>
Sent: Monday, October 14, 2024 10:56:43 PM
To: microsoft/lisa @.>
Cc: Raheel Abdul Faizy @.>; Mention @.>
Subject: Re: [microsoft/lisa] Debian 13 Arm16 testing (PR #3472)
@rabdulfaizyhttps://github.com/rabdulfaizy I gave you write permission of this repo. please create test branches, not PRs.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/lisa/pull/3472#issuecomment-2412475283, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BMBDB6AVVJOYS65NWEUY6K3Z3RD2XAVCNFSM6AAAAABP2AXXFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJSGQ3TKMRYGM.
You are receiving this because you were mentioned.Message ID: @.***>

Closing the PR.

authors: rabdulfaizy squirrelsc


text:
Possible regression: NavigationView.ItemInvoked raised before selected item is updated

With the last few pre release versions of WinUI, starting with 2.4.0-prerelease.200113001, ItemInvoked get's raised before the actual selection has changed, that is the selected item is out of sync when checking in ItemInvoked. In versions prior to 2.4.0-prerelease.200113001, the selected item was set before ItemInvoked was raised. Is this breaking change intentional?

It is likely not intentional but @anawishnoff @ojhad can confirm.

I think this needs to be fixed.. @chingucoding would you like to look into it?

Sure, if that behavior is not wanted, I will gladly fix this.

It is likely not intentional but @anawishnoff @ojhad can confirm.

Yep, this behavior should be fixed.

authors: StephenLPeters chingucoding ojhad ranjeshj

repo: microsoft/microsoft-ui-xaml


text:
Fix NavigationView light dismiss issue

Description
Fixes the NavigationView light dismiss issue where the NavigationViewItems would not work with the correct closed pane width.
Implementation details
I removed the check if the navigation pane (a SplitView pane) is closed. When we close the pane using the pane toggle button (or set SplitView.IsPaneOpen to false), we were already entering the ListSizeCompact visual state. In other words, splitView.IsPaneOpen() returned false. However, if the pane was light dismissed, splitView.IsPaneOpen() returned true at this point, thus not entering the ListSizeCompact visual state, causing the issue to manifest.
Now that the check is removed, we enter this visual state no matter how the navigation pane is closed . And since we are only calling this code in a handler for the event when the pane is closing (OnSplitViewPaneClosing) having removed this check should not introduce any other side-effects.
Motivation and Context
Fixes #2208
How Has This Been Tested?
Tested visually.
Screenshots
See the following GIF:

@chingucoding Good point. Added an interaction test now.

@Felix-Dev can you please merge with master which includes some stability fixes for the PR pipeline ?

@ranjeshj Done.

/azp run

authors: Felix-Dev ranjeshj


text:
Delete unused #define

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Thank you for submitting this PR, the current focus of the team is to assist our users in moving from WinUI 2 to WinUI 3. We are closing this PR as it does not address resolving a critical issue for WinUI 2 or WinUI 3.

@gabbybilka A recently merged PR https://github.com/microsoft/microsoft-ui-xaml/pull/7570 have removed some dead code. Is this PR any different?
I could cleanup multiple things at once and removing lots of dead code in a single PR, if you wish.


text:
How can I make the Monaco editor fully support nodejs code assist and highlighting?

Context

[X] This issue is not a bug report. (please use a different template for reporting a bug)
[X] This issue is not a duplicate of an existing issue. (please use the search to find existing issues)

Description
I am planning to use Monaco editor as a code editor for my electron project.
But I encountered a small problem, the project requires users to enter nodejs code in the editor.
But I found that the Monaco editor does not support CommonJS code assist.
Here is my Webpack config:
const MonacoEditorPlugin = require('monaco-editor-webpack-plugin')

module.exports = {
    plugins: [
        new MonacoEditorPlugin({
            languages: ['javascript', 'css', 'html', 'typescript', 'json']
        })
    ]
}

Here is my code:
let codeEditor = monaco.editor.create(document.getElementById("editor-section"), {
        value: "function hello() {\n    console.log('Hello world!');\n}",
        language: "javascript",
        automaticLayout: true,
        minimap: {
          enabled: false
        },
        cursorSmoothCaretAnimation: true,
        scrollBeyondLastLine: false,
        scrollBeyondLastColumn: 0
      });

Here is the final effect:

How can I configure the Monaco editor so that it can assist nodejs code correctly?
If there is no such way, how can I turn off this CommonJS module to ES module prompt? This prompt is wrong and will mislead the user.
node version: v16.13.2
webpack version: ^5.69.0
webpack-cli version: ^4.9.2
electron: ^17.0.1
monaco-editor: ^0.32.1

Did you find answer? Have the same question (:

repo: microsoft/monaco-editor