vscode-dotnet-runtime/vscode-dotnet-runtime-exten.../package.json

155 строки
7.3 KiB
JSON
Исходник Постоянная ссылка Обычный вид История

2024-07-17 02:44:05 +03:00
{
"name": "vscode-dotnet-runtime",
"repository": {
"type": "git",
"url": "https://github.com/dotnet/vscode-dotnet-runtime.git"
},
"bugs": {
"url": "https://github.com/dotnet/vscode-dotnet-runtime/issues"
},
"license": "MIT",
"author": "Microsoft Corporation",
"displayName": ".NET Install Tool",
"description": "This extension installs and manages different versions of the .NET SDK and Runtime.",
Add new API `dotnet.findPath` to find the .NET host to use if one already exists that meets a requirement. (#1954) * 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>
2024-10-01 01:31:09 +03:00
"connectionString": "InstrumentationKey=02dc18e0-7494-43b2-b2a3-18ada5fcb522;IngestionEndpoint=https://westus2-0.in.applicationinsights.azure.com/;LiveEndpoint=https://westus2.livediagnostics.monitor.azure.com/;ApplicationId=e8e56970-a18a-4101-b7d1-1c5dd7c29eeb",
2024-07-17 02:44:05 +03:00
"icon": "images/dotnetIcon.png",
"version": "2.2.4",
2024-07-17 02:44:05 +03:00
"publisher": "ms-dotnettools",
"engines": {
Allow uninstallation of global .NET Installations (#1897) * 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
2024-08-16 01:22:20 +03:00
"vscode": "^1.81.1"
2024-07-17 02:44:05 +03:00
},
"categories": [
"Other"
],
"keywords": [
".NET",
".NET Core",
"dotnet",
"Extension Authoring",
"runtime"
],
"capabilities": {
"untrustedWorkspaces": {
"supported": true
},
"virtualWorkspaces": true
},
"activationEvents": [
"onStartupFinished"
],
"main": "./dist/extension.js",
"types": "./dist/extension.d.ts",
"contributes": {
"commands": [
{
"command": "dotnet.reportIssue",
"title": "Report an issue with the .NET Install Tool.",
"category": ".NET Install Tool"
},
{
"command": "dotnet.acquireGlobalSDKPublic",
"title": "Install the .NET SDK System-Wide.",
"category": ".NET Install Tool",
"enablement": "!dotnetAcquisitionExtension.isGlobalSDKUnsupported"
Allow uninstallation of global .NET Installations (#1897) * 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
2024-08-16 01:22:20 +03:00
},
{
Allow uninstallation of global .NET Installations (#1897) * 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
2024-08-16 01:22:20 +03:00
"command": "dotnet.uninstallPublic",
"title": "Uninstall .NET.",
"category": ".NET Install Tool"
2024-07-17 02:44:05 +03:00
}
],
"configuration": {
"title": ".NET Install Tool",
"properties": {
"dotnetAcquisitionExtension.enableTelemetry": {
"type": "boolean",
"default": true,
"description": "Enable Telemetry for the .NET Install Tool. Restart VS Code to apply changes."
},
"dotnetAcquisitionExtension.enablePreviewFeatures": {
"type": "boolean",
"default": false,
"description": "Enable Preview Features for the Extension. Restart VS Code to apply changes."
},
"dotnetAcquisitionExtension.installTimeoutValue": {
"type": "number",
"default": 600,
"description": "Timeout for installing .NET in seconds."
},
"dotnetAcquisitionExtension.existingDotnetPath": {
"type": "array",
2024-09-19 02:49:50 +03:00
"markdownDescription": "The path to an existing .NET host executable for an extension's code to run under, not for your project to run under.\nRestart VS Code to apply changes.\n\n⚠ This is NOT the .NET Runtime that your project will use to run. Extensions such as `C#`, `C# DevKit`, and more have components written in .NET. This .NET PATH is the `dotnet.exe` that these extensions will use to run their code, not your code.\n\nUsing a path value in which .NET does not meet the requirements of a specific extension will cause that extension to fail.\n\n🚀 The version of .NET that is used for your project is determined by the .NET host, or dotnet.exe. The .NET host picks a runtime based on your project. To use a specific version of .NET for your project, install the .NET SDK using the `.NET Install Tool - Install SDK System-Wide` command, install .NET manually using [our instructions](https://dotnet.microsoft.com/download), or edit your PATH environment variable to point to a `dotnet.exe` that has an `/sdk/` folder with only one SDK.",
Add new API `dotnet.findPath` to find the .NET host to use if one already exists that meets a requirement. (#1954) * 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>
2024-10-01 01:31:09 +03:00
"description": "The path to an existing .NET host executable for an extension's code to run under, not for your project to run under.\nRestart VS Code to apply changes.\n\n⚠ This is NOT the .NET Runtime that your project will use to run. Extensions such as 'C#', 'C# DevKit', and more have components written in .NET. This .NET PATH is the 'dotnet.exe' that these extensions will use to run their code, not your code.\n\nUsing a path value in which .NET does not meet the requirements of a specific extension will cause that extension to fail.\n\n🚀 The version of .NET that is used for your project is determined by the .NET host, or dotnet.exe. The .NET host picks a runtime based on your project. To use a specific version of .NET for your project, install the .NET SDK using the '.NET Install Tool - Install SDK System-Wide' command, use the instructions at https://dotnet.microsoft.com/download to manually install the .NET SDK, or edit your PATH environment variable to point to a 'dotnet.exe' that has an '/sdk/' folder with only one SDK.",
2024-07-17 02:44:05 +03:00
"examples": [
"C:\\Program Files\\dotnet\\dotnet.exe",
"/usr/local/share/dotnet/dotnet",
"/usr/lib/dotnet/dotnet"
]
},
"dotnetAcquisitionExtension.sharedExistingDotnetPath": {
"type": "string",
2024-09-19 02:49:50 +03:00
"description": "The path of the preexisting .NET Runtime you'd like to use for ALL extensions. Restart VS Code to apply changes.",
2024-07-17 02:44:05 +03:00
"examples": [
"C:\\Program Files\\dotnet\\dotnet.exe",
"/usr/local/share/dotnet/dotnet",
"/usr/lib/dotnet/dotnet"
]
},
"dotnetAcquisitionExtension.proxyUrl": {
"type": "string",
"description": "URL to a proxy if you use one, such as: https://proxy:port"
2024-09-19 02:49:50 +03:00
},
Add new API `dotnet.findPath` to find the .NET host to use if one already exists that meets a requirement. (#1954) * 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>
2024-10-01 01:31:09 +03:00
"dotnetAcquisitionExtension.allowInvalidPaths": {
2024-09-19 02:49:50 +03:00
"type": "boolean",
"description": "If you'd like to continue using a .NET path that is not meant to be used for an extension and may cause instability (please read above about the existingDotnetPath setting) then set this to true and restart."
2024-07-17 02:44:05 +03:00
}
}
}
},
"scripts": {
✒️ Enable ESRP Signing on the .VSIX (#1885) * 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 ecacc6830bcd39bb628651f6e234956b5840faef. * 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 1ab6ea1873ad8a9e81b9fdb0ecbd62e558e7f09f. * Update name of incorrect task.
2024-08-12 21:04:24 +03:00
"vscode:prepublish": "npm run compile-all && npm install && webpack --mode production && dotnet build ../msbuild/signJs --property jsOutputPath=..\\..\\vscode-dotnet-runtime-extension\\dist -bl -v:normal",
2024-07-17 02:44:05 +03:00
"compile": "npm run clean && tsc -p ./",
"watch": "npm run compile && tsc -watch -p ./",
"test": "npm run compile --silent && node ./dist/test/functional/runTest.js",
"clean": "rimraf dist",
"compile-all": "cd ../vscode-dotnet-runtime-library && npm install && npm run compile && cd ../vscode-dotnet-runtime-extension && npm install && npm run compile",
"lint": "eslint -c .eslintrc.js --ext=.ts vscode-dotnet-runtime-library/src/**/*.ts vscode-dotnet-runtime-extension/src/**/*.ts --ignore-pattern \"**/test/\" --fix",
2024-07-17 02:44:05 +03:00
"webpack": "webpack --mode development"
},
"dependencies": {
"@types/chai-as-promised": "^7.1.8",
"@vscode/test-electron": "^2.3.9",
"axios": "^1.7.4",
2024-07-17 02:44:05 +03:00
"axios-cache-interceptor": "^1.0.1",
"axios-retry": "^3.4.0",
"chai": "4.3.4",
"glob": "^7.2.0",
"https-proxy-agent": "^7.0.2",
"mocha": "^9.1.3",
"open": "^8.4.0",
"rimraf": "3.0.2",
"shelljs": "^0.8.5",
"ts-loader": "^9.5.1",
"typescript": "^5.5.4",
2024-07-17 02:44:05 +03:00
"vscode-dotnet-runtime-library": "file:../vscode-dotnet-runtime-library",
"webpack-permissions-plugin": "^1.0.9"
},
"devDependencies": {
"@types/chai": "^4.3.5",
"@types/mocha": "^9.0.0",
"@types/node": "^20.0.0",
2024-07-17 02:44:05 +03:00
"@types/rimraf": "3.0.2",
"@types/source-map-support": "^0.5.10",
"@types/vscode": "1.74.0",
"copy-webpack-plugin": "^9.0.1",
"webpack": "^5.88.2",
"webpack-cli": "^4.9.1"
2024-07-17 02:44:05 +03:00
},
"__metadata": {
"id": "1aab81a1-b3d9-4aef-976b-577d5d90fe3f",
"publisherDisplayName": "Microsoft",
"publisherId": "d05e23de-3974-4ff0-8d47-23ee77830092",
"isPreReleaseVersion": false
}
}