dotnet
/
vscode-dotnet-runtime
зеркало из https://github.com/dotnet/vscode-dotnet-runtime.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
vscode-dotnet-runtime/vscode-dotnet-runtime.code-...

25 строки
491 B
Plaintext
Исходник Обычный вид История

Split into 3 projects. - We now have a library, an extension and a sample. - The library is the core of all logic dotnet core acquisition related. - The extension is the actual VSCode extension that is shipped but acts like a shell to host the logic from the library. - The sample acts as a dependent extension that needs .NET Core tooling
2019-05-08 03:22:59 +03:00
{
"folders": [
{
Renaming folders to match new extension name
2020-01-25 01:12:14 +03:00
"path": "vscode-dotnet-runtime-extension"
Split into 3 projects. - We now have a library, an extension and a sample. - The library is the core of all logic dotnet core acquisition related. - The extension is the actual VSCode extension that is shipped but acts like a shell to host the logic from the library. - The sample acts as a dependent extension that needs .NET Core tooling
2019-05-08 03:22:59 +03:00
},
Adding SDK extension plumbing
2021-02-09 20:37:28 +03:00
{
"path": "vscode-dotnet-sdk-extension"
},
Split into 3 projects. - We now have a library, an extension and a sample. - The library is the core of all logic dotnet core acquisition related. - The extension is the actual VSCode extension that is shipped but acts like a shell to host the logic from the library. - The sample acts as a dependent extension that needs .NET Core tooling
2019-05-08 03:22:59 +03:00
{
"path": "sample"
},
{
Renaming folders to match new extension name
2020-01-25 01:12:14 +03:00
"path": "vscode-dotnet-runtime-library"
Split into 3 projects. - We now have a library, an extension and a sample. - The library is the core of all logic dotnet core acquisition related. - The extension is the actual VSCode extension that is shipped but acts like a shell to host the logic from the library. - The sample acts as a dependent extension that needs .NET Core tooling
2019-05-08 03:22:59 +03:00
}
],
Track which Extensions Own Which Installs (#1748) * WIP - Migrate Install Key strings to type to allow future flexibility with installs -- e.g. non-versioned install folder names so we can auto update. Start collecting more information during install about who installed it so we can ref count them for uninstalls. Does not migrate telemetry events or other code yet which needs to be experimented on further * WIP - Migrate all code to use InstallKey Type & Fix Bugs There are several big things here that might seem like small code changes. 1 - Before when we found a 'partial install' we would delete ALL local runtimes. I am astounded this exists. There are other extensions that might depend on those other runtimes and this just deletes it from underneath them. A partial install is rare, I think you need to pkill vscode or something since the install script runs out of proc. We consider an install partial if our code never got to mark it as installed after calling the install script. Its rare but does happen, at 2010 occurences out of 470k in recent days. Renames a function which appears to handle partial installs to clarify it only manages local ones. Gets rid of some unused functions or moves them to a better place. Renames IInstallKey to DotnetInstall. The install key is the string representing the directory of the install. It shouldn't have two meanings. Add logic for ref counting which extensoins own which installs. * wip - record extension owner for installs Fix record keeping to properly ref count extensions Rename types to match standard better Still need to figure out how to manage uninstalling and 'graveyard' as well as how to remove a 'legacy' install via version when it is a dotnetinstall object. * Separate out 'graveyard' code or management of old installs to another class * Dont pull files from dist - bad copilot, bad * Update some more of the code to use new types * update mock objects to get the build working * respond to linter * Add back in the old telemetry prooperties I got rid of them because they are duplicated data. But TBH there are a lot of things that rely on the pre-existing property names. It would be much harder to query new and old data together if getting rid of them, so I added them back even though it causes some data duplication. * Fix bugs with install management * add missing semicolon lol * Fix a bug with clearing out the installed list The logic was missing a !. * Fix Install Graveyard Logic * Fix test logic for legacy installs * Skip unnecessary preinstall local sdk check on global sdk * Add back code to account for preinstall in sdk status check * Remove unnecessary string checks We never give a string to this class anymore so it's not needed * Add event for when tracking installs messes up somehow * Refactor classes out to many more files * Respond to linter * Isolate install tracking management to a separate class * Clean up acquisition worker and remove unnecessary logic * Port the worker to using an external install manager to isolate protected data * Respond to linter concerns * Remove potential deadlock with installation management * Increase timeouts With the change where you need to hold a lock to edit extension state to protect against timing challenges where an install is being added or deleted at the same time and can cause incorrect behavior, we had to slow down the product. * Migrate to a singleton for install tracker so no dupliacte lock is created * Working build for changing 'isRuntime' to mode for 'aspnet' 'sdk' or 'runtime' * undo the singleton in test as the context needs to be per test * remove the singleton pattern as it will result in a bug with multiple acquisition requests having a stale context * Add Tests for Install Tracking with who owns what install * improve timeout on test * Revert "improve timeout on test" This reverts commit a4168f6ec57c7360cdd3b8e20b35ad792b6ccf6c. * fix timeout * Fix Test * Fix Logic for adding pre existing installs * Fix tests to be successful * Code Cleanup & Remove Potential Tech Debt for Modes remove places where we make assumptions on the existing model (sdk or runtime) to prevent future tech debt * respond to linter * Fix bug with context being in a different mode than a legacy installation Mark old function as deprecated and add a comment explaining why our assumption there works Fix possible bugs with context management where context could be a different mode than what was previously installed which could cause future bugs down the line that would be hard to track down * Add back in removed events to prevent breaking old telemetry dashboards * Final Code Review from Me * Fix Test * Remove circular dependency from test artifact * add missing file header from refactor * fix test * delete directory per mode file as there is a git bug where changes in file caps is not being picked up * Add back into directory file with proper capitilzation per git bug * Add missing await which might cause test to fail inconsistently * Make the lock based timeout based on the user setting for timeouts
2024-06-05 03:07:38 +03:00
"settings": {
"cSpell.words": [
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
"aspnetcore",
Add Support for ASP.NET Installation (#1843) * wip - separate out worker paths so contexts are needed for every call, but there is less potential for things to go wrong and less code duplication * Further isolate code, need to isolate the install tracker now * migrate install tracker to use event stream instead of being coupled to the context * move installtracker to a singleton and fix tests the install tracker really only needs to exist once since the event stream and extension state are global, this will prevent errors from different states of promises and simplify our code with this design pattern to decouple the installation tracking mechanism from the context object, which will reduce code duplication for aspnet install feature additions * Fix some issues with the test during code migration * Fix issue with accessing instance I forgot to ctrl s! * Clean up logic with install key generation * Remove duplicate source of truth for architecture * Improve logging and error handling of install tracker This class is super annoying to debug without better logging * Update some broken components of the tests * Prevent saying object object in the log output by expanding the object * Tests working We used to need to concat these tests results with different contexts but not any longer * FIx uninstall all commands * Fix the file rename * Improve logging messages * Add mode handling for aspnet * Add ASP NET Support * Add Generic -> Mode Specific Event Stream Class Hierarchy * [wip] create events for all 'modal' events * Dont hold a generic arg obj because it becomes too unwieldy * Fix some issues with the test and sdk extension * Add 'mode' to the acquire context This will allow API callers to set the mode to call aspnet without having to write a new endpoint call. We can default to runtime for when it wasnt provided that would be the old behavior. * Move 'installMode' into the acquire context This allows API callers to provide the mode, We remove it from the worker context to dedupe this and prevent 2x sources of truth. Now this is a bit weird because some API endpoints will take the mode even though the API endpoint is only for one mode. We will just ignore the mode for that. Eventually we can try to transition all of the related calls to a single endpoint based on 'mode' which would simplify API usage. * Code cleanup * De-Dupe Test Code * Add Requested Events to Republisher * Update InstallKey pattern to include ~aspnetcore This is a bit strange since - used to be for 'global' and ~ for architecture. There are only so many path safe characters to use, more importantly though we dont rely on the install key as the information for the install anymore, it is stored in the DotnetInstall object. ~ has logic in place to not account for a 'legacy' install, so ~ with aspnet (which would not have existed before arch was added) is also a bet that will work with pre-existing logic. * fix build issues * Add ASP.NET Directory Provider * Only Report Total Success if Path exists The path can be undefined if an error throws so its not a success * Add ASP.NET API to sample extension * Resolve Asp Net Runtime versions as Runtime versions * Fix mistake on test * Fix bug with install script param * add source-map-support to allow build in CI this got removed and passed earlier somehow * respond to linter * add source map support * Respond to linter * Add test for specific telemetry messages * 2.0.7 branding * Prevent circular import * rewrite completion event so we can test the modaleventrepublisher * fix linter issue * Revert new test since the object is not mockable * Get rid of check for event that cannot be published via mocks * Fix bug where logging was not up to date to prevent i/o costs the file is dumped at the end of error handling, but this means other events past error handling dont get added to the log. This fixes this. * respond to pr feedback
2024-06-25 20:22:20 +03:00
"DOTNETINSTALLMODELIST",
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
"dotnets",
Handle .NET Failed: Undefined (#1930) 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.
2024-08-21 01:34:04 +03:00
"Republisher",
"unlocalized"
Track which Extensions Own Which Installs (#1748) * WIP - Migrate Install Key strings to type to allow future flexibility with installs -- e.g. non-versioned install folder names so we can auto update. Start collecting more information during install about who installed it so we can ref count them for uninstalls. Does not migrate telemetry events or other code yet which needs to be experimented on further * WIP - Migrate all code to use InstallKey Type & Fix Bugs There are several big things here that might seem like small code changes. 1 - Before when we found a 'partial install' we would delete ALL local runtimes. I am astounded this exists. There are other extensions that might depend on those other runtimes and this just deletes it from underneath them. A partial install is rare, I think you need to pkill vscode or something since the install script runs out of proc. We consider an install partial if our code never got to mark it as installed after calling the install script. Its rare but does happen, at 2010 occurences out of 470k in recent days. Renames a function which appears to handle partial installs to clarify it only manages local ones. Gets rid of some unused functions or moves them to a better place. Renames IInstallKey to DotnetInstall. The install key is the string representing the directory of the install. It shouldn't have two meanings. Add logic for ref counting which extensoins own which installs. * wip - record extension owner for installs Fix record keeping to properly ref count extensions Rename types to match standard better Still need to figure out how to manage uninstalling and 'graveyard' as well as how to remove a 'legacy' install via version when it is a dotnetinstall object. * Separate out 'graveyard' code or management of old installs to another class * Dont pull files from dist - bad copilot, bad * Update some more of the code to use new types * update mock objects to get the build working * respond to linter * Add back in the old telemetry prooperties I got rid of them because they are duplicated data. But TBH there are a lot of things that rely on the pre-existing property names. It would be much harder to query new and old data together if getting rid of them, so I added them back even though it causes some data duplication. * Fix bugs with install management * add missing semicolon lol * Fix a bug with clearing out the installed list The logic was missing a !. * Fix Install Graveyard Logic * Fix test logic for legacy installs * Skip unnecessary preinstall local sdk check on global sdk * Add back code to account for preinstall in sdk status check * Remove unnecessary string checks We never give a string to this class anymore so it's not needed * Add event for when tracking installs messes up somehow * Refactor classes out to many more files * Respond to linter * Isolate install tracking management to a separate class * Clean up acquisition worker and remove unnecessary logic * Port the worker to using an external install manager to isolate protected data * Respond to linter concerns * Remove potential deadlock with installation management * Increase timeouts With the change where you need to hold a lock to edit extension state to protect against timing challenges where an install is being added or deleted at the same time and can cause incorrect behavior, we had to slow down the product. * Migrate to a singleton for install tracker so no dupliacte lock is created * Working build for changing 'isRuntime' to mode for 'aspnet' 'sdk' or 'runtime' * undo the singleton in test as the context needs to be per test * remove the singleton pattern as it will result in a bug with multiple acquisition requests having a stale context * Add Tests for Install Tracking with who owns what install * improve timeout on test * Revert "improve timeout on test" This reverts commit a4168f6ec57c7360cdd3b8e20b35ad792b6ccf6c. * fix timeout * Fix Test * Fix Logic for adding pre existing installs * Fix tests to be successful * Code Cleanup & Remove Potential Tech Debt for Modes remove places where we make assumptions on the existing model (sdk or runtime) to prevent future tech debt * respond to linter * Fix bug with context being in a different mode than a legacy installation Mark old function as deprecated and add a comment explaining why our assumption there works Fix possible bugs with context management where context could be a different mode than what was previously installed which could cause future bugs down the line that would be hard to track down * Add back in removed events to prevent breaking old telemetry dashboards * Final Code Review from Me * Fix Test * Remove circular dependency from test artifact * add missing file header from refactor * fix test * delete directory per mode file as there is a git bug where changes in file caps is not being picked up * Add back into directory file with proper capitilzation per git bug * Add missing await which might cause test to fail inconsistently * Make the lock based timeout based on the user setting for timeouts
2024-06-05 03:07:38 +03:00
]
}
Split into 3 projects. - We now have a library, an extension and a sample. - The library is the core of all logic dotnet core acquisition related. - The extension is the actual VSCode extension that is shipped but acts like a shell to host the logic from the library. - The sample acts as a dependent extension that needs .NET Core tooling
2019-05-08 03:22:59 +03:00
}