* Consider Runtime Patch Versions in PATH API
The C# extension will now fail if the runtime is not 8.0.10 or higher on mac so we need to support patch version lookup.
Sadly we cannot migrate to semver because semver rejects strings such as 8.0 which are allowable in many parts of our code and APIs.
This also adds code for SDK lookup but no test since that's harder to test, like remarked in the code.
* Fix test
* Fix the version logic to not only parse major.minor version
We now parse all of the version, dont need to do this logic.
* Fix Version Parsing for FindPath API
The old comparison used string comparison which is fine for versions of dotnet until dotnet 10. '10.0' < '9.0'. 😂 This fixes that. I suppose it's a bit clunky and we could dedupe / share the compare logic but it's not being used elsewhere in this same form, so I don't plan to do that right now. There are also places that depend on the output versions being strings, so that's a problem to change that now too. It probably should have been a class from the beginning but unfortunately that just isn't how it was initially done, which is understandable because the scope at that time was much more limited.
* Fix some of the code
* Fix test
* Dont comment out the other tests
* update comment
* Always Return `IDotnetAcquireResult` or `undefined` instead of sometimes a string on `findPath` API
The current findPath API can return a `IDotnetAcquireResult` (which is just an object with `dotnetPath : string`) if the existingDotnetPath is returned, but otherwise it will return a string. This is a mistake. I would like to break it as quickly as possible before it has more widespread adoption.
The class gives us more flexibility to add more information in the future besides the path string without breaking people.
I also added return type annotations to the functions so this does not happen again.
* Fix comment
* Fix test
* Fix incorrect PATH echo
* Add Architecture Check into Find PATH API
We had a discussion about how Mac users tend to need the arm64 runtime and often have the x64 host installed on their PATH. This was a big concern. With global installs at least we can still rely on the output from `dotnet --info` for now, so we decided to add this back in.
* Fix test, the runtime install does not have an arch printed so we cant quite use it to check properly
* Fix test
* Fix test
* undo comment out
* Fix a very terrible bug due to a typo
* code cleanup
* Try asking the user if the want to continue
* Add a message on mac if someone tries to cancel the installation
Consider that to tell if the user wanted to say 'no' or 'yes' to retry, that doesnt indicate whether they meant to do the install or not. We would then need more options to tell if we actually failed or not. I dont want to rely on this and I dont think it is a high enough priority with the complexity required to reroute the code to add a retry button that does a certain retry depending on if someone clicked to cancel the install on mac
* Consider if the dotnet file doesnt exist but the folder does
* Fix bug
Certain events get sent way too often (ex: 700 million locks acquired over a few months which is causing problems for the data team) and aren't useful for telemetry.
We allow suppressing certain events before even hitting the data ingestion service by doing a check here.
I made a change a while back such that 'cancelled request' style errors dont cause a pop up because I figured they were not useful. The vendors reported it as a bug. Do you think we should keep a pop up for those types of errors?
The types of errors include: entered a bad version, you cancelled the password prompt or admin prompt, you have a custom linux install or conflicting feeds, your distro is not supported, etc
Resolves https://github.com/dotnet/vscode-dotnet-runtime/issues/1826
If this is closed, close this issue.
Waiting for PM feedback on @baronfel. I think we can display it.
Extensions can set errorConfiguration in the acquire context
export declare enum AcquireErrorConfiguration {
DisplayAllErrorPopups = 0,
DisableErrorPopups = 1
}
to ignore this.
* Add back output for uninstall in the terminal
Resolves https://github.com/dotnet/vscode-dotnet-runtime/issues/1920
There used to be this code to print a message to the terminal when an uninstall is going on. It got deleted at some point.
* Clean up import
2.0, 2.1, etc were never available on the server hosting download files for .NET and we don't need to support that. This updates the sample test for vendors to run to use versions of aspnet that are supported so this test actually functions properly.
* add publish task
* move template out of steps and into jobs
* get rid of pool
* dont pass 1es pool
* add depends on chain
* use vsce latest
* run package on publi
* add approval step:
* vsixs are stored in the root, so don't check in the extension folder
* Switch to MI instead of a PAT
* Fix ps1 issue
* Only deploy on internal
* Use pool vs vmimage
* Try to fix pool condition
* Use a different pool
* Condition the name of the build based on OS
Why is windows the bomb emoji and not the windows emoji?
And why did I do this:
The windows build goes last because its in alphabetical order based on the behavior of how devops works. This is bad because it should go first and makes the other steps take longer as they depend on only the windows task. The bomb emoji is one of the first emojis thats not an emoticon before the penguin emoji so I picked that one..
* It's pretty silly you cant define a variable in a template but here we are
* Maybe it has to be in plaintext
* The deployment step is not necessary
* wait for wait job
* Set the emoji
* Move windows to the top
* Set 'use 1es pool' to true
* Switch to a different ordering so windows runs first, then linux
* try to fix bug where version is not passed and publish args is wrong
* Try to pass var into another job since we cant have a template in the jobs
* Revert "Try to pass var into another job since we cant have a template in the jobs"
This reverts commit 7bdf2dfec9.
* Try to condition the yamls omewhere else
* is yaml failing
* Revert "is yaml failing"
This reverts commit b014dd042f.
* Revert "Try to condition the yamls omewhere else"
This reverts commit 7ccb36f01c.
* Revert "try to fix bug where version is not passed and publish args is wrong"
This reverts commit 592349be71.
* Get version again
We cant return a value from a template
We cant make a template callable with jobs in another job
We cant pass a variable from one job to another if its a job in a job
We cant do so many things in yaml
* yaml indentation
* Don't skip checking out the repo, we kinda need that to get the version
By passing recursive:true to all mkdirSync calls we protected against
issues that may arise from parent directories not already existing.
Fix#1985
Co-authored-by: Andy Sleigh <andy.sleigh@healthhero.com>
Microbuild is failing credscan following TSA upload. It has several issues and the pipeline is publishing artifacts to the root artifacts staging directory and CredScan is considering everything under that path as part of the pipeline output. MicroBuild is being installed there, so it is incorrectly being brought into the scan.
This repo does not own microbuild, we only do it for signing.
* Branding for version 2.2.0
Bumping to a new major version considering the stabilization of the new dotnet find path API.
* Update vscode-dotnet-runtime-extension/CHANGELOG.md
* Permit Installing .NET via a package.json file
Extensions that rely on .NET often have a slow startup time due to our existing API.
For extensions that want the .NET runtime to be installed as soon as possible, they can now also make an API request in their package.json.
They should add a [IDotnetAcquireContext](https://github.com/dotnet/vscode-dotnet-runtime/blob/main/vscode-dotnet-runtime-library/src/IDotnetAcquireContext.ts) object in a section titled 'x-dotnet-acquire' to do so. They don't need to include the `requestingExtensionId`, since this is already in their `package.json`,
This should go at the root of a `package.json`, and not in the `contributes` section.
```
"x-dotnet-acquire": {
"version": "8.0",
"mode": "aspnetcore"
}
```
We run the install on startup and also whenever a new extension is installed via the onDidChange API. https://code.visualstudio.com/api/references/vscode-api#Extension<T>
You can easily test this by modifying the SDK extension and adding this, then packging t with `vsce`, installing it, and running the Runtime Extension under the Debug tab. If you do so, you will see that:
If you install a new extension, the request is made.
If you had already installed the extension, the request is also made.
* Respond to linter
* Add a very basic test.
* Fix typo
* Fix typo
* update PATH setting description to make it more clear
* add very prototype code
* add tests and get runtime check working
* Fix some bugs
* Consider that the .NET SDK can also satisfy the Runtime
* fix typo
* fix the tests
* fix
* fix another test
* Fix tests even more
* undo yarn changes
* fix the final test hopefully
* undo yarn changes
* Dont use dotnet.exe as its not platform agnostic
* use "markdownDescription" for nicer rendering in VSCode
* Tweak call to action to use VSCode mechanisms first, then our standard installation docs, and only in the last resort mention PATH munging.
* Fix URLs
* Move to version 2.1.7
* add basic command'
* Ignore existingPath setting for SDK installs.
C# DevKit never uses the path returned by our installation. This means users would think this path would change the sdk that this extension uses but that is not the case. This path to dotnet.exe is meant to be the path for the runtime for extensions to run on, and not the SDK path. It's confusing that the setting was used for both and a misstep in a way. DevKit is the main caller of this API so we think we can change this with minimal breakage.
* Remove warning setting and fix invalid path setting
The setting must be accessed earlier. This means vscode will need to be restarted. We also update the readme and messaging a bit so its more publicly clear in all places what the setting is for.
* Fix test
* Refactor code out into a Validator for Conditions
dotnet --list-runtimes and more need to be called in more places. This is a separate task so it should be done. I did not change the code in any way except for adding the requirement clause type.
* Prepare code to validate the path
* add a lot of prototypey code
* add comment for future work
* merge with main
* look up the architecture
* Improve the code
* Go 2 Directories Up to find the True Path on PATH
* Final initial loop of API code
* Fix bug parsing list runtimes
* Add tests
* Fix test and search for where if its not installed
* Consider where may return multiple values
* Fix test
* tests mostly working
* code cleanup - get rid of extra api to set env
* Restore the env var so we dont edit it for other processes
* Uncomment the remaining tests
* Respond to lint
* fix callback
* Fix path to be os-gnostic
* Only search for where on windows and also search for which
* provide env to the find command so /usr/bin/whcih can be used
* Call which which instead of which so the correct command can be found
* Install 3.1 instead of 7.0 because the DTL CI machines seem to have a 7.0 SDK on them :zany:
* give up on arch check for now because it is inaccurate, see comment
* Add github issue in comment for context
* make linter happy
* Respond to PR feedback
* Migrate to connection strings
Resolves https://github.com/dotnet/vscode-dotnet-runtime/issues/1958
The old application insights key was created by @LakshanF, when we migrated to the new vscode-extension-telemetry service, their API had a breaking change to require a connection string instead of an insights key. https://github.com/dotnet/vscode-dotnet-runtime/pull/1948
The connection key can be public and is hard coded. Our existing key has been in our open source, source code for many years. Here is what their guidance says: https://www.npmjs.com/package/@vscode/extension-telemetry
> Follow guide to set up Application Insights in Azure and get your connection string. Don't worry about hardcoding it, it is not sensitive.
* Respond to PR Feedback
---------
Co-authored-by: Chet Husk <chusk3@gmail.com>
TS Lint failed this `Unexpected `await` of a non-Promise (non-"Thenable") value`.
But the callback can be a promise type. Its just not smart enough to realize that.
* update PATH setting description to make it more clear
* add very prototype code
* add tests and get runtime check working
* Fix some bugs
* Consider that the .NET SDK can also satisfy the Runtime
* fix typo
* fix the tests
* fix
* fix another test
* Fix tests even more
* undo yarn changes
* fix the final test hopefully
* undo yarn changes
* Dont use dotnet.exe as its not platform agnostic
* use "markdownDescription" for nicer rendering in VSCode
* Tweak call to action to use VSCode mechanisms first, then our standard installation docs, and only in the last resort mention PATH munging.
* Fix URLs
* Ignore existingPath setting for SDK installs.
C# DevKit never uses the path returned by our installation. This means users would think this path would change the sdk that this extension uses but that is not the case. This path to dotnet.exe is meant to be the path for the runtime for extensions to run on, and not the SDK path. It's confusing that the setting was used for both and a misstep in a way. DevKit is the main caller of this API so we think we can change this with minimal breakage.
* Remove warning setting and fix invalid path setting
The setting must be accessed earlier. This means vscode will need to be restarted. We also update the readme and messaging a bit so its more publicly clear in all places what the setting is for.
* Fix test
---------
Co-authored-by: Chet Husk <chusk3@gmail.com>
* upgrade to the newest version of extension telemetry
* remove vscode-extension-telemetry where its not needed
* Update vscode-test as well since its a new library
* 2.1.6 branding
* add other potential mac path from installer/generatePKG.targets -- need to add tests
* fix tests
* Simplfiy expression logic
Co-authored-by: Michael Yanni <MiYanni@microsoft.com>
* Fix syntax
---------
Co-authored-by: Michael Yanni <MiYanni@microsoft.com>
* get eslint running but its failing a lot of checks
* Fix the linting after migration
* Fix many errors
* 65 errors to go
* fix almost every lint issue
* clean lint
* Remove references to tslint
* dont install eslint as it is already here
* install eslint
* update eslint
* dont empty cache because eslint is failing to register the types that exist
* try to help eslint find the files for type defs
* Set typescript resolver
* Fix imports
* Add some import plugin but still cant import vscode correctly
* install eslint globally
* skip npm installl
* add imports
* try to fix the import issue
* build before hand so the types are picked up -_____-
* Revert "build before hand so the types are picked up -_____-"
This reverts commit e5381b42df.
* rollback to eslint 8 but still run build
* Encase the installer path in quotes to protect against spaces in username being parsed poorly, and other path issues. Don't know why we didnt do this before.
* fix linter
Rejecting a promise with a rejected promise as a return value from a function does not reject with the object the inner promise rejected with. Instead it rejects with an undefined value.
This means if the SDK installer fails or we fail to elevate, that counts as .NET Install failed: undefined. This fixes this. It also adds a check for the string error as this seems to happen sometimes if the password prompt is rejected.
How to test this? Set a break point in win mac global installer on the execute install and edit the command to point to a non existent file. It will then fail and you can see it works now.
* Fix an issue parsing promises
We changed the function `getPromise` to not use a lock in version 2.1.2. This was a mistake. I thought it would return the unresolved `Promise` object if it was a sync function. That is not the behavior, instead it will skip that line of code and return null even if the promise exists. This causes multiple processes to try to grab the installer file handle.
When one fails to grab the file handle, it causes a chain-reaction of cascading failures for concurrent requests, because that is supposed to be blocked from happening.
In addition, the check I added to kill the sudo process once it is finished runs on all platforms despite the master sudo process only being present on Linux, which has resulted in some higher timeout rates. We need to not do this on other platforms.
* Fix tests
we need to clear the promise out after each test is done
* dont call uninstall all in sdk test, its the wrong command
* reset event stream in the test
* 2.1.4 branding - new version due to vscode marketplace outage causing failure to upload version 2.1.3 correctly
* 2.1.5 branding prepare for a new version
bump the version after 2.1.4 was released and skipping a version due to vscode outage
* Fix an issue parsing promises
We changed the function `getPromise` to not use a lock in version 2.1.2. This was a mistake. I thought it would return the unresolved `Promise` object if it was a sync function. That is not the behavior, instead it will skip that line of code and return null even if the promise exists. This causes multiple processes to try to grab the installer file handle.
When one fails to grab the file handle, it causes a chain-reaction of cascading failures for concurrent requests, because that is supposed to be blocked from happening.
In addition, the check I added to kill the sudo process once it is finished runs on all platforms despite the master sudo process only being present on Linux, which has resulted in some higher timeout rates. We need to not do this on other platforms.
* Fix tests
we need to clear the promise out after each test is done
* dont call uninstall all in sdk test, its the wrong command
* reset event stream in the test
* 2.1.4 branding - new version due to vscode marketplace outage causing failure to upload version 2.1.3 correctly
* Fix an issue parsing promises
We changed the function `getPromise` to not use a lock in version 2.1.2. This was a mistake. I thought it would return the unresolved `Promise` object if it was a sync function. That is not the behavior, instead it will skip that line of code and return null even if the promise exists. This causes multiple processes to try to grab the installer file handle.
When one fails to grab the file handle, it causes a chain-reaction of cascading failures for concurrent requests, because that is supposed to be blocked from happening.
In addition, the check I added to kill the sudo process once it is finished runs on all platforms despite the master sudo process only being present on Linux, which has resulted in some higher timeout rates. We need to not do this on other platforms.
* Fix tests
we need to clear the promise out after each test is done
* dont call uninstall all in sdk test, its the wrong command
* reset event stream in the test
* Add failure handling for file integrity check
This is now what is hitting the EPERM and ENOENT errors.
We need to skip the check and see what happens from here, such as allowing to elevate via windows.
This also adds specific handlers for when we fail to download the SDK.
* elevate on windows
* Retry if no permission is available the first time
Need to double check that cancelling is handled properly now that its a promise reject
* respond to linter
* Add API to uninstall any install
* Add tests
* undo bad save
* dont uninstall if there are multiple owners
* add some basic uninstall capability
* allow elevation on mac
* fix promise chain a bit, may need to await still
* add uninstall functionality to linux
* add uninstall on linux
* fix merge
* Add a test
* add ui element to pick uninstall
we need to fix the uninstallglobal functoin logic to print out and such still
then test it
* add some output, need to test and check graveyard
* add uninstall events
* fix build
* Fix uninstall to pop up above window
* ui changes per request
* fix test
* fix merge err
* fix mac test
* fix name option
* fix promise logic
* fix promise code again xd
* Add icons for the extension
* add icons to shield and uninstall
* set minimum vscode version to require new icons
* dont sort if no install exists
* use noninteractive frontend in master process to fix dpk unable to re open stdin on uninstall
* try to exit sudo process master and set env var for stdin uninstall fix
* fix eventstream
* fix detection logic for uninstall
* add -y to uninstall
* fix bug with uninstall
* add version check for when disk is full and version string ui fails
* also kill sudo process on uninstall
* use -f to delete file as they may not exist and we dont want to fail due to this at the end
* add -y to update
* respond to linter
* remove unnecessary img
* respond to linter
* respond to pr feedback
* fix when extension may have null record
* add function to call in extensoin.ts for offline mode acceptAlternativeVersions on acquirectx
* refactor version helper functions outside of version resolver
version resolver is a class that is based around using the internet. It probably should have been like this before.
* add code to check existing installing versions
* Update test name
* respond to linter
* Update lint
* Fix bugs and add messages
* respond to pr feedback
* move signing prep into another template so we can not push microbuild to staging directory
* condition the signing prep
* fix the cond since yaml has dumbest syntax ever
* fix whitespace i hate yaml
* remove junk:
* succeded doesnt work
* Add fake MSBuild project to allow signing VSIX and JS
* Sign JS
* Add step to pipeline
* Restrict signing package version
* Add scripts to install signing tool locally
* only go up 1 directory
* fix display name
* fix whitespace -__-
* add build step for installing microbuild
* add sign type parameter
* dont produce alpha package in official drop
* add sign type parameter to default pipeline
* dont publish package in another directory as this causes other issues, instead copy the artifact
* acknowledge the existence of a document explaining the release and other maintenance processes
this information is more suited for internal repo changes.
* change internal stream to a different signing stream
* add dotnet public for notargets sdk
* reduce to 1 feed
* use a different feed
* Use dotnet team
* use explicit feed source
* add feed auth
* fix comment
* rename unsigned vsix so both can get dropped
* use the other type of slash for REN -__-
* try to fix path
* add packages folder with empty gitignore
* figure out dir
* fix rename command
* Fix rename
the 'unsigned' one is actually the signed one
* Fix JS File Sign
dist is at the root of each but this runs in a segregated folder
* produce binlogs and try to fix the path
* Publish SDK Extension Logs
* fix signing
* remove bad slash in path that gets parsed incorrectly
* remove \
* fix microbuild to be installed b5 js signing
* update gitignore
* fix gitignore again
* [REVERT THIS] Add a file A.ts to see if files are signed alphabetical or only non minified JS is signed
* [REVERT THIS] Add content to js to see if minify changes signing
* sign js after webpack
maybe we can sign it after the bundle is created and it will still be able to edit the bundle vsix internals? I thought not but perhaps extension.js is getting replaced by the webpack, so lets see if this works.
* Revert "[REVERT THIS] Add content to js to see if minify changes signing"
This reverts commit ecacc6830b.
* Revert "[REVERT THIS] Add a file A.ts to see if files are signed alphabetical or only non minified JS is signed"
This reverts commit 1ab6ea1873.
* Update name of incorrect task.
* Add failure handling for file integrity check
This is now what is hitting the EPERM and ENOENT errors.
We need to skip the check and see what happens from here, such as allowing to elevate via windows.
This also adds specific handlers for when we fail to download the SDK.
* elevate on windows
* Retry if no permission is available the first time
Need to double check that cancelling is handled properly now that its a promise reject
* respond to linter
* allow elevation on mac
* fix promise chain a bit, may need to await still
* Fix offline detection
8.8.8.8 blocks our requests. We can use microsoft.com instead, if our app is checking using microsoft, well, if microsoft is down we've learned that the app will have problems anyways , so if that is down it doesnt matter as much.
* fix variable name
* respond to linter
* respond to PR feedback, fix whitespace and ??
* add some fixes for lock, amend
* Use a separate lock for install vs installing
This will yield performance improvements.
* remove change that snuck in from another pr
* fix linter
* make functions not async if they dont need to be
* Hot fix for installation record tracking
We renamed it from 'key' to 'id' because the string 'key' is filtered out of all log events via vscode because 'key' looks like a secret. We did this in a rush and vendor testing did not have pre-existing machine state to realize the old data structure would still be in the local memory for pre-existing users. This converts the data in memory to the new type.
* Prevent adding corrupted installation records into the data
Noah Gilson
Ishita Agarwal
andysleigh
Noah Gilson