Installing .Net Core and Visual Studio Code on Chromebook

Having a portable light-weight development environment is important to me. I’m always on the lookout for a solution. There have been a number of solutions I’ve found for which I’ve been optimistic, but over a longer period of time they just haven’t worked out. Samsung had Linux on Dex, which allowed certain phones to run a full Ubunto Linux environment. But they later discontinued it and removed support for it. Microsoft Windows2Go, which allowed a full Windows environment to be installed on a portable USB drive and moved from one computer to another. I still have a few of these drives and use them, but Windows has dropped support for them and replacement drives are hard to find. I’ve managed to use a Raspberry Pi as a portable development environment before too. But now I have what looks to be an improved option. Many Chromebooks support a Linux environment.

I’m using a Samsung Chromebook Plus. While the unit that I have is older, it has seen some significant changes throughout its life. When I first received it, to edit code I had to use a code editor from the Chrome store. This was nowhere near the best editor that I have used, but it worked. The Chromebook later gained the ability to run Android applications. In the Google Play Store there were some code editors, but once again, not the best. My Chromebook has had a linux environment on it for a while, and I’ve recently installed the Visual Studio Code. Finally! A **real** code editor!

Before installing .Net Core or Visual Studio Code, the Chromebook must be enabled for Linux. Not all Chromebooks support this feature. To enable this feature, open the Chromebook settings. Search for “Linux.” If your Chromebook supports Linux you will see the option “Turn on.” Press the button and wait a few moments. The Chromebook will install the components needed for Linux. After the installation is complete, you may need to restart your Chromebook. Once the Chromebook has restarted you will have the program “Terminal” on your computer. If you open this, you will be within the Linux environment. Update the environment, and install a text editor to use at the terminal.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install nano

From within the terminal, you can install dotnet core the same way that you would on a Raspberry Pi. Visit and select “Downloads.” You will see options for downloading the .Net Framework or .Net Core. Select the “all .Net Core Downloads” link. The next screen has a list of the .Net Core downloads. At the time of this writing the most recent version is the .Net Core version 5.0. Select it to see the builds. My Chromebook uses an ARM processor, though there are some that use x86 processors. For my Chromebook I must download the ARM 32-bit Linux version. The next page will share a direct download link. Copy this link and open the terminal.

In the terminal, use the wget command to download the .Net Core installation. For the current version the command looks like the following.


After a few moments, the installation has downloaded. To install it, we must make a folder into which it till be installed, unpackage the tar file, and add this folder to the path.

sudo mkdir /usr/share/dotnet
sudo tar xvf name_of_archive.tar.gz
sudo nano ~/.profile

That last command will open your .profile file, which contains a list of commands that are run when you login. Go to the end of the file and add these two lines.

export PATH=$PATH:/usr/share/dotnet
export DOTNET_ROOT=/usr/share/dotnet

.Net Core is installed, but we need to restart the Linux environment before it will work. Right-click on the terminal icon in the task bar and select the option to “Shut down Linux.” When open it again, the changes will be applied. If you find yourself opening the terminal frequently.

Installing Visual Studio Code is easier. Navigate to You will see links to different editions of Visual Studio. Select the one for Visual Studio Code. Select the option to see More. On the next page select the download for the Linux deb ARM build of Visual Studio Code. After the file downloads, find it in your file system and double-click on it. An installer window will open. Select the option to Install. For me, the installation progress bar does not move for quite some time before it showed any change. After the installation is complete you can start it by typing ‘code’ in the command terminal or by finding it in your list of installed program.

Unencrypted HTTP on Android

Most network resources that I access with the Android applications that I build communicate over HTTPS. It isn’t often, but I sometimes access a resource over an unencrypted connection. This is usually the case for home automation and media control devices. One example of such an application is a Roku remote that I made for myself; the Roku accepts HTTP requests to simulate presses on the remote control. When I create something that needs to access resources over unencrypted HTTP, there’s a step I usually forget that leaves me wondering why I am receiving null responses back from my request.

When Android P was released, Google implemented a change to encourage developers to use encrypted HTTPS instead of unencrypted HTTP.

As part of a larger effort to move all network traffic away from cleartext (unencrypted HTTP) to TLS, we’re also changing the defaults for Network Security Configuration to block all cleartext traffic. You’ll now need to make connections over TLS, unless you explicitly opt-in to cleartext for specific domains.

Android Developer Blog, Dave Burke, BP of Engineering for Android

The most recent time that I forgot to enable unencrypted communication was perplexing. I was communicating with a device over UDP and HTTP, and I saw that the device was responding to the UDP requests and was a bit confused before I remembered the step that I had missed.

To enable unencrypted clear text communication generally within an application, there is an additional attribute that must be added to the <application> element in the application’s manifest.


That is going to enable HTTP traffic for all domains. I used this option for communication over a local network since there isn’t a specific domain that I can target for someone’s home connection. When there is a specific domain that your application must communicate with, you can create a network security policy permitting unencrypted communication to that domain. Before doing this, consider what information that your application is sending. If there is any personally identifying or sensitive information in your messages, then this option is not acceptable. If for some reason you cannot enable HTTPS (such as the domain being controlled by another entity) and you’ve reviewed the risks and consider them acceptable, then you can move forward with allowing unencrypted communication with that domain. To do that, you will need to create a new XML file resource in res/xml, giving it the name of your choosing. The contents of the file will look like the following. You will need to place the domain(s) of interest in the configuration.

<?xml version="1.0" encoding="utf-8"?>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true"></domain>

In the application’s manifest, add a reference to this policy. Assuming the above file is named “network_security_config.xml” the manifest entry would look like the following.

<application android:networkSecurityConfig="@xml/network_security_config" ... />

While using SSL/HTTPS is generally preferable and lower risks, there may be times when you must fallback on unencrypted clear text communication. When this happens, for Android-P and later your application must explicitly opt-in to clear text communication.

A Cellular Connection for the Raspberry Pi

I recently setup the Simcom 7600 on a Jetson Nano. When I spoke of it I had mentioned that there is also a version of the cellular model that is specifically made for the Raspberry Pi. After a few delivery delays I have one in my hands and am looking at it now. Since both the Pi and the Jetson are Linux based ARM devices and the models are both using the same chipset my expectation is for the setup to be similar. There are two primary versions of the device. The version that I am using was released in 2020 December. There are some slight differences in the labels on the headers between these models. The version that I use is also without an SD card slot. Some of the older versions have these.

When you purchase a Simcom 7600, there is usually a letter following that number. The letter lets you know which variant that you have. Different variants are best supported by mobile networks in different regions. E-H work best in Southeast and West Asia, Europe, and Africa. A-H are primarily for North America, Australia, New Zealand, Taiwan, and Latin America.

The Simcom 7600 connects to a Pi the same way you would connect any other hat. Well, mostly. There are some options in how it is connected. The most obvious way is to connect the 4G hat to the 40-pin connector. I used this method. To do so, I had to remove the cooling fan that I had on my Pi. Included in the box are a couple of standoffs and screws for securing the 7600 to the board. Personally, I feel that a Pi that is using a mobile connection should also have its own battery. To secure the board and my batter I had to use a different set of standoffs. But I’ve got everything working (minus the cooling fan).

The Simcom 7600 for the Pi has a couple of USB ports and jumpers on it. Before powering it on, I went to the documentation to see what these were all for. Starting with the yellow header, there is a jumper already bridging PWR and 3V3. This is to set a power-on option. In this default state, the SIMCOM 7600 will turn on any time that it receives power. If the jumper is moved to bridge PWR and D6, then the SIMCOM 7600 will be off by default, but the Pi can control the power state itself. A user can also control the state through the power button on the side of the device. A third option is to remove the jumper entirely. If the jumper is removed then the only way to control the devices power state is manually using the power button.

In addition to controlling power, you now also have the option to place the device in flight mode. The control flight-mode with the pi, bridge pins D4 and Flight with a jumper. If the jumper is present then then flight mode is controllable through software.

Just behind the headphone jack are another set of jumpers. The purpose of these headers was not immediately obvious to me at first. They are not mentioned in the manual. But they show up on the schematic for the SIMCOM 7600. This header is for deciding how communication with the SIMCOM 7600 will occur.

SIMCOM 7600 Communication Jumpers

The pins that lead to the SIMCOM chip itself are the TXD 3.3V and RXD 3.3V. These lines pass through a line converter to raise the signals to the voltage level that the SIMCOM uses. If the jumpers are in their top position (connecting U_RX to TXD 3.3V and U_TX to RXD 3.3V) then communication with the SIMCOM will occur over USB (specifically USBJ1). In the middle position, communication with the SIMCOM occurs over the Raspberry PI 40 pin header on pins 8 and 10 (P_TX and P_RX). In the lowest position, the USB port connects to the Pi with there being no connection made to the SIMCOM chip.

There is a second USB port on the board. What is that for? The second USB port connects directly to the SIMCOM itself. It has USB interface pins on the chip itself. That means that there are two ways to communicate with the SIMCOM 7600 chip.

There are only a few lines on the 40-pin header that interact with the SIMCOM 7600. I could restore the heatsink and fan to my SIMCOM 7600 and still allow the Pi to communicate over USB along with a few other lines. But I prefer to have the board secured to the Pi.

Leaving the settings in their default state, I’ll be communicating with the SIMCOM 7600 over both USB and using the 40-pin header. To minimize the number of things that I could forget to do that would result in the board being non-responsive, I’m going to leave it bolted to the board though to keep it more secure.

Before setup, ensure that you’ve updated the packages on your Raspberry Pi

sudo apt-get update
sudo apt-get upgrade

Ensure that the serial port on the pi is enabled. From the Pi desktop upen the Pi menu, select “Preferences.” Then select “Raspberry Pi Configuration.” In the Interfaces tab select “Enable” next to the “Serial Port” item. If it were not enabled before, you will need to reboot after you enable it.

Shutdown your Pi and remove power from it. Attach the 4G hat to the Pi and power it back up. You should see the Power light on the Pi illuminated solid red. If the Pi detects a cellular signal, the Net light will blink. If it is solid, ensure that you have securely attached the antenna and have the SIM card in place.

Open a command terminal and type

sudo lsusb

You will see some serial devices listed. Connect the Pi and the cellular modem using the USB port that is next to the cellular antenna. Then, from the command terminal, run the lsusb command again. You should see an additional item of hardware. If you do, then the Pi has detected the modem.

Let’s get the software installed. The drivers for the modem are in a *.7z file. You will need to install a tool for unarchiving the file. You also need to have a tool for interacting with the serial port.

sudo apt-get install minicom p7zip-full

Download and unpackage the example code for the SIMCOM 7600. Along side this sample code is the driver that is needed for the Raspberry Pi.

7z x SIM7600X-4G-HAT-Demo.7z -r -o/home/pi
sudo chmod 777 -R /home/pi/SIM7600X-4G-HAT-Demo

When the Pi boots up, we want it to initialize the SIMCOM board. To ensure this happens, open /etc/rc.local and add the following line.

sh /home/pi/SIM7600X-4G-HAT-Demo/Raspberry/c/sim7600_4G_hat_init

After initialization, you can start interacting with the Pi hat. As a test that it is responding, you can connect to it using the minicom utility and send some AT commands and see that is responds. You can connect to it using either port /dev/ttyUSB2 or /dev/ttyUSB3.

minicom -D /dev/ttyUSB2 -b 115200