Restore VS Code After Windows Updates Remove It

Overview

Windows updates are meant to improve system stability, but occasionally, they restructure important folders, leading to unexpected issues. One problem some users have encountered is VS Code files being moved to a mysterious _ folder inside its installation directory. If this happens to you, don’t worry you can restore VS Code easily with a simple script!

Understanding the Issue

After certain Windows updates, your VS Code installation folder (C:\Users\{YourUsername}\AppData\Local\Programs\Microsoft VS Code) may contain a subfolder called _. Instead of properly maintaining the installation structure, the update isolates essential VS Code files within this _ folder, making it difficult for the application to launch correctly.

How to Fix It Manually

1. Open File Explorer and navigate to:

C:\Users\{YourUsername}\AppData\Local\Programs\Microsoft VS Code

1. If you see a _ folder, open it.
2. Move all its contents back to the parent directory.
3. Restart VS Code to ensure everything works normally.

Automate the Fix with a Script

If you want a one-click solution, this batch script will detect the misplaced files, prompt you for confirmation, and move them back automatically:

@echo off
setlocal

:: ==============================================================
:: Restore VS Code After Windows Updates Remove It
:: ==============================================================
:: Some Windows updates mistakenly move VS Code files into a "_" 
:: subfolder inside its main installation directory. This script 
:: checks if the folder exists and prompts the user before restoring 
:: the files to the correct location.
:: ==============================================================

:: Define the VS Code installation directory
set "vscodeDir=%USERPROFILE%\AppData\Local\Programs\Microsoft VS Code"

:: Define the misplaced folder path
set "underscoreDir=%vscodeDir%\_"

:: Check if the "_" directory exists
if not exist "%underscoreDir%" (
 echo No misplaced files found. Nothing to fix!
 exit /b
)

:: Prompt user for confirmation
echo A misplaced folder ("_") was found inside the VS Code installation directory.
set /p userInput=Do you want to move its contents back to the parent folder? (Y/N): 

:: Convert input to uppercase to handle lowercase entries
if /I not "%userInput%"=="Y" (
 echo Operation canceled.
 exit /b
)

:: Move files back to the parent directory
echo Moving files back to parent directory...
move "%underscoreDir%\*" "%vscodeDir%"
echo Done! The misplaced files have been restored.

endlocal

How to Use the Script

• Copy the code into Notepad.
• Save it as restore_vscode.bat (make sure it’s saved as All Files, not a .txt file).
• Run the script by right-clicking and selecting Run as administrator.
• If the _ folder exists, the script will ask for confirmation before moving the files.
• Press Y and hit Enter to restore your VS Code files.

Automating the Process for Future Updates

If you find this problem recurring after every update, consider automating the fix:

• Task Scheduler: Set up a scheduled task to run this script after each Windows update.
• Startup Folder: Place the script in the Windows startup directory so it runs on boot.

By using this script, you’ll save time and frustration, ensuring VS Code remains fully functional after every Windows update.

Thanks for reading and follow me for more technical articles, videos and podcasts

• GitHub
• Twitter
• YouTube
• BlueSky

👍 Originally published by ozkary.com

How to Manage JavaScript Project Dependencies with NPM

When working with JavaScript projects, we use the Node Package Manager (NPM) to manage our package dependencies. NPM is a Command Line Interface (CLI) tool that enables developers to add, remove, and update package dependencies in our projects.

Due to security vulnerabilities, bugs and enhancements, there is a high frequency of updates on these dependencies, and developers need to keep track of those updates to avoid accumulating technical debts on their projects, or even worse, to allow for a security vulnerability to continue to run on a production environment.

With this understanding, it is important to be familiar with the process to keep a JavaScript project up to date with the latest package updates. This enables us to clearly understand the steps that are required to check on the dependencies’ configuration, outdated versions, commands to manage the updates, and what to do to force an upgrade to major versions.

Understand the Project Dependencies

To get a better understanding of how to manage our project dependencies, we need to understand how a project is configured. When using NPM to manage a React, Angular or other JavaScript framework project, a package.json file is created. This file host both the release and development dependencies, the latter is used only for tooling to aid in the development and build effort and are not deployed.

The one area to notice from this file is how the semantic version (semver) range rules are defined. Basically, these rules govern how far ahead in new versions a dependency can be updated. For example, look at the following configuration:

 

"scripts": {     "build": "tsc", }, "dependencies": {     "jsonwebtoken": "^8.5.1",         "mongoose": "~5.3.1",     "node-fetch": "^2.6.7"   },   "devDependencies": {     "@azure/functions": "^3.2.0",     "@types/jsonwebtoken": "^8.5.9",     "eslint": "^7.32.0",     "jest": "^26.6.3",     "typescript": "^4.8.2"   }

The dependency version is prefixed with a notation, most commons characters are the caret (^) for minor versions and tilde (~) for patch versions. These characters are designed to limit a project upgrade to only backward compatible versions, for example:

• ^8.5.1 Can only upgrade up to the max minor version 8.x.x but never to 9.x.x
• ~5.3.1 Can only upgrade to the max patch version 5.3.x but never to 5.4.x

It is important to follow the semver governance to maintain backward compatibility in your projects. Any attempts to upgrade to a major release will introduce breaking changes, which can require refactoring of the code.

Check for Outdated Versions

Now that we understand how a project is configured, we can now move forward to talk about how to check for outdated dependencies. To check all the version on our project, we can run the following npm command:

> npm outdated

This command reads the package.json file and checks the version of all the dependencies. In the image below, we can see the output from this command:

 

The output shows each package name, its current version, the wanted version which is governed by the semver range, and the latest package available. Ideally, we want to upgrade to the latest package available, but if that version is not within your semver range, there is the risk of many breaking changes, which requires some code refactoring. 

 

Note: Notice the font color on the package name, red indicates that an update is required

Update the Dependencies

So far, we have identified that some packages are behind in updates or outdated. The next step is to use npm and apply the update to our project, which is done by using another npm command:

 

> npm update

 Note: In Linux and WSL, if you see the EACCES error, grant the current user permissions by typing this command: sudo chmod 700 /folder/path

The update command reads all the packages and applies the new version following the semver range rules. After running the command, the output, if no errors were found, should look like the following images:

From this output, we can see that all the current versions match the wanted version. This basically means that the current version is updated with the latest minor release for that version. This is the safe way to update of the dependencies, but overtime, there will be a need to force your project to update to a new major release. How do we do that?

How to Upgrade to a Major Version

In some cases, there may be a security vulnerability, a feature that does not exist in the minor version, or just is time to keep up with the latest version, and there is a need to move up to the next major version or even the latest version. Most of the time, it is sufficient to move to the next major version when the project is not too far behind updates.

 

When this is the case, we can force update a version by running another npm command, which help us upgrade to a specific version or the latest one.

> npm install –save package-name@3.0.0 or > npm install –save package-name@latest

 

The install command is not bound by the semver constraint. It installs the selected version number or the latest version. We also provide the –save parameter to save the changes to the package.json file, which is really important for the next update. This will update the reference to the new version number.

 

When upgrading to a new major version, there are some risks in introducing some breaking changes. Usually, these changes are manifested on deprecated functionality that may no longer exists or operate differently. This forces the dev team to have to refactor the code to meet the new technical specifications.

Verify the Updates

After applying the dependency update to a project, it is important to verify that there are no issues with the update, especially when upgrading to a major version. To verify that there are no issues, we need to build the project. This is done by using the build script in the package.json file and running the command npm run build

 

"scripts": {     "build": "tsc", },   > npm run build

 

The package.json file has a script node where we can define commands to run the build, test cases and code formatting tasks. In this example, tsc stand for TypeScript Compiler. It builds the project and check for any compilation issues. If there are any compatibility problems, the output of the build process will indicate where in the code to find the problem.

 

The npm run command enables us to run the script that are defined within the script node of the package.json file. In our case, it runs the tsc command to do a build. This command may look different in your project.

Conclusion

When we start a new project, we use the current package versions that are available from the npm repository at that time. Due to security vulnerabilities and software updates, there is a high frequency of updates in these JavaScript packages. Some of these new versions are backward compatibles, others are not. It is always an issue of technical debt when we let our projects get far behind in updates, so we most frequently check for outdated software and plan for major version updates when necessary. Therefore, become one with npm and use it to help manage a project package dependency.

npm run happy coding

Send question or comment at Twitter @ozkary

Originally published by ozkary.com

Visual Studio Code Online - Quick Intro

Visual Studio Code (VSCode) Online is a browser hosted IDE for software development purposes. It works similarly as the full version of VSCode.  You can access VSCode Online by visiting https://vscode.dev.  

After the IDE is loaded on your browser, you can connect to any GitHub repo, including repos from other services. As the project loads, you are able to interact with the files associated to the project. These files can be JavaScript, TypeScript, CSharp or any other programming language associated to the project.

As a developer, you are able to browse the files, make edits commit and push back the changes to your repo. In addition, you can debug, do code comparison or load other add-ons to enable other development activities.

This service is not meant to replace your development environment, but is an additional tool to enable your work. Do take a look, and let me know what you think by sending my a message at Twitter @ozkary

Take a look at this video for a quick demo of the tool.

Send question or comment at Twitter @ozkary

Originally published by ozkary.com

DevOps Set Default Azure Subscription with Azure CLI

DevOps for Azure configuration and deployment is a key component of cloud operations management without having the need to use the Azure user interface. When there are multiple subscriptions to manage, we need to make sure that we first select the correct subscription from Azure. We can take a look at how this can be done using Azure CLI 2.0  (install from this site).

CodeProject

After opening the Bash command shell, follow these steps:

Login to Azure

We can login to our Azure account using the login command. This requires some browser interaction to enter a code for the two factor authentication.

az login

List Our Subscriptions

After a successful login, we can list all of our current subscription using the account command.

az account –list –all –output table

We can see the returning JSON with a list of accounts that are available in a nice table format.  Each reference has a name and isDefault property. Only one of them is our default subscription.

Set a Default Subscription

We can change our default subscription by running the account set command.

az account set  --subscription “my subscription name”

Validate Default Subscription

We should be able to list all the subscriptions again and verify that the default subscription is correct by filtering the results using GREP. (Note this work when using Bash)

az account –list –all –output table | grep “True”

The result should be only the subscription that is set to IsDefault = true.

At this point, we should be on the right subscription, and we can move forward with any additional configuration using Azure CLI.

Originally published by ozkary.com

SharePoint Create a host-named Site with PowerShell

On SharePoint, we usually create site collections using the path-based route. This approach aligns very well with the SharePoint online/Office 365 site structure recommendations. With SharePoint 2013, we can create a site collection using a host-named site which allows us to assign a unique DNS name to our site collections. This enables us to deploy multiple sites with different DNS names in the same web application.

CodeProject

Path-named vs Host-named

Site Collection Structure	Example
Path-named	ozkary.com/sites/demosite1
Host-based	demosite1.ozkary.com

In order to deploy a host-named site, we need to create a DNS entry that points to the SharePoint host server/farm. We then need to write some code using PowerShell as this feature is not available from the Admin Central.

To create the site collection, we run this custom function from PowerShell with elevated permissions.

#

# Name: createHostNamedSite

#

# Description:  Creates a host-named site collection

# Usage

# createSite web-app-name, dns-entry site-name site-description admin-account-name site-template content-database

#

createHostNamedSite "ozkary.com" "https://demosite1.ozkary.com" "Demo Site 1" "Demo Site 1 Description" "admin-account" "STS#0" "WSS_Content_DB"

Parameter Information

Parameters	Description
Web-app-name	Main SharePoint web app name where site collections are hosted
Dns-entry	The unique DNS entry for the site
Site-name	The name for the site collection
Site-description	The site description
Admin-account-name	The site collection owner usually the admin
Site-template	A site template like team site, document center Click here to see more templates
Content-database	The content database for this site collection

createHostNameSite Function

Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue

#

#  Name: createHostNameSite

# 

#  Description: create a host-named site collection

#

#  Params:

#       $webAppName 

#       $siteUrl

#       $siteName

#       $description

#       $owner

#       $template

#       $contentDatabase 

#

function createHostNameSite($webAppName, $siteUrl, $siteName, $description, $owner,$template, $contentDatabase)

{   

    write-host "Creating site with parameters " $webAppName, $siteUrl, $siteName, $description, $owner,$template, $contentDatabase , $mapUrl

    $continue = Read-Host -Prompt "Do you want to continue (y/n)"

    if ($continue -eq "y")

    {

        write-host "Provisioning Site...."       

        New-SPSite $siteUrl  -Name $siteName -Description $description -OwnerAlias $owner -Template $template  -ContentDatabase  $contentDatabase  -HostHeaderWebApplication (Get-SPWebApplication $webAppName)               

    }else{

        write-host "Process cancelled"

    }

}

On the code , we first include the SharePoint plug-in which enables us to use the New-SPSite cmdlet that handles all the hard work for us.  Another area to notice is that there is the HostHeaderWebApplication parameter for which we pass the SharePoint web application reference by using the Get-SPWebApplication cmdlet. This is what enables us to create the host-named site.

After the site is created, we should be able to type the DNS name, and if it is already created and propagated in your network, the request should be able to be sent to SharePoint which can load the corresponding site properly.

I hope this is helpful and enjoy your site creation automation (DevOps) with PowerShell. 

Originally published by ozkary.com