Showing posts with label Powershell. Show all posts
Showing posts with label Powershell. Show all posts

Monday, January 20, 2020

How to list installed .NET Framework versions using PowerShell

Getting installed .NET Framework versions is (surprisingly) not a simple task. On this post, let's try to address that.

When .NET developers have to fix problems on a remote server that requires knowing which versions of the .NET Framework are installed, they'll be frustrated. Unfortunately, the Redmond folks made it unnecessarily complicated to know the installed versions of the .NET Framework on a  Windows box.

.NET Core on the other side, does it well via the .NET Core CLI. But for those of us still on the .NET Framework, what can we do? The official documentation, describes multiple options including accessing the registry, using PowerShell and building a C# application.

Listing the installed folders

The simplest and fastest solution is obviously listing the contents of the folders .NETFramework folder with:
dir "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework"
While that's usually sufficient to list what's installed, it does not confirm IF the frameworks are correctly registered in the system. To confirm that everything's correctly setup we'll have to use PowerShell as described next.

Listing the frameworks using PowerShell

To list which frameworks are installed directly from the Windows Registry can be found on this PowerShell script:

Simplifying Further

Ok, but let's assume that we're on a remote server. Opening chrome and downloading this script might not be ideal. Could we somehow script this out? Yes, by using PowerShell's Invoke-WebRequest (PowerShell's curl), we could make it a one-liner so that we don't have to even open a browser and download that script from GitHub. Here is it:
Invoke-WebRequest -Uri https://github.com/hd9/powershell/raw/master/list-dotnet-frameworks.ps1 -OutFile list-dotnet-frameworks.ps1; .\list-dotnet-frameworks.ps1
Hope it helps!

See Also

For more posts on .NET Core, please click here.

Monday, June 4, 2018

Installing and Running RavenDB on Windows and Linux

Let's install and run RavenDB on Windows and Linux and learn how it works.

On a previous post  I introduced RavenDB on this blog. On this one let's review how to install or run a standalone RavenDB instance on our machine.

On this post we will cover:
  1. Installing and running on Windows;
  2. Installing and running on Linux;
  3. Using the RavenDB console tool;
  4. Creating a new database;

Downloading RavenDB

First off, navigate to the RavenDB downloads page and download the server version for the environment you're working on. The currently supported platforms are: Windows, Linux, OSX, Raspberry PI and Docker.

To download your image, select Server, Stable and the appropriate version for your environment. Aaccept the terms, click on the .ZIP Package download button to download the image to your disk.

Running standalone RavenDB on Windows

On Windows, once the download is completed, extract all those files in a folder and you'll see two PowerShell files: run.ps1 and setup-as-service.ps1.

Open the Powershell terminal, cd into the folder you extract your files and run .\run.ps1 You'll then see some outputs the RavenDB service is emitting for us when running as a standalone instance:
A new window will open for you where you'll need to configure a cluster and/or security. For now, let's skip the cluster configuration and go with the Unsecure option. 

This configuration is enough for this demo and simple development efforts. Clicking on it, RavenDB Studio will open on the default Url: http://127.0.0.1:8080/studio/index.html.
That's it! The standalone instance is running and you can start testing RavenDB on your Windows box.

Installing on RavenDB Windows

To install you your machine,  open the PowerShell terminal as an administrator and run the setup-as-service.ps1 script.

If all goes well, you'll  have to accept the user license agreement and proceed with the instance configuration.

Note that:
  • the installation requires administrator privileges
  • will use port 8080 for "unsecure" installs or 443 for secure (options selected during the installation)

Configuring the new Instance

After installed, you'll have to configure your instance as shows the image below. For a development setup, you should be good with the Unsecure option.
Clicking on it, will prompt you for Http/Tcp ports and IP address. Leaving empty will use the defaults. Click "Restart Server" and RavenDB should be installed.

The RavenDB Service

Once installed, on Windows, we can view the service status using the Get-Service Powershell cmdlet:
Get-Service -Name RavenDB

For more information, please visit: https://ravendb.net/docs/article-page/4.0/csharp/start/installation/setup-wizard

Running standalone RavenDB on Linux

The Linux installation is similar: download your Linux image from the RavenDB downloads page, unzip it and run the script. Let's see how it works.

Download the image by selecting Linux x64 from the downloads page and download it using Firefox:
Once downloaded, extract the bz2 pkg on a local folder:

Cd into that folder and run "run.sh". I should then see:

Installing RavenDB on Linux

Installing RavenDB on Linux is very similar to Windows. You run the run.sh shell script and select the installation option on the command line.

The RavenDB Console

After installed, basic manipulation of the server can be done either by using the Raven UI (Raven Studio) or by using the console previously opened.

For example, when I type help on my shell in Fedora, I get:
From the console, You can do things like restarting/shutting down the server, like exporting/importing data, reading logs and viewing server stats. Just type the commands shown. For example, to shut the instance down, I should type: shutdown.

Creating a Database

The final needed step before touching code is to create a database. For that do: Databases -> New Database:
Enter a DB name (for example, "Blog") and click "Create"):
Clicking on that Database creates our database and takes us to the its page. From there we basically can view our documents (records), create, query, patch, view logs, stats, etc:

Next Steps

Now that RavenDB is running and the database is created, the next step is to start interacting with it. You can use either RavenDB Studio or the client Api (with C#, Java, Python, etc). For more details, check my simple introduction to RavenDB.

Don't forget that RavenDB is also available on the cloud. Check the article An in depth review of the RavenDB Cloud for more information.

Conclusion

Hope this post shows how is a simple introduction on how to install RavenDB on Windows and Linux boxes. For more information, check the official documentation.

Monday, December 18, 2017

Getting last modified software on Windows using PowerShell

Getting the list of the last modified software on Windows is actually simple, if using PowerShell
Photo by Miti on Unsplash
Whenever I get requests like "hey, how can I get the lastly installed software on my machine?", I try to resolve them with code and as simple as possible. Turns out that on Windows, PowerShell can be an excellent tool for scripts like those. On this post, let's address that using PowerShell and review how it became a fun, simple and quick exercise.

Using Get-WmiObject

The Get-WmiObject cmdlet is what we need to get Windows diag information. By combining it with Export-Csv we can export all installed software on our machines with:
Get-WmiObject -Class Win32_Product | Export-Csv installed.csv

Using Get-ChildItem

The next part consists in using the Get-ChildItem cmdlet to filter out our exported data. That can be done with:
# getting last modified files
Get-ChildItem C:\ -rec | sort LastWriteTime | select -last 1000 | Export-Csv files.csv

Conclusion

Doing this simple exercise was fun, simple and quick using PowerShell. Don't know PowerShell yet? I would urge you to take a look and learn it (even if just the basics). PowerShell is a powerful tool used extensively in devops on Windows, Azure and Linux.

Oh, and yes, I really don't miss the days before PowerShell!

Monday, December 11, 2017

PowerShell - The server committed a protocol violation

Let's understand what that error means and review 3 different ways to fix it.
Photo by Max Rovensky on Unsplash

This sort article details a good trick for those getting the following error in PowerShell: 
The server committed a protocol violation
After googling ducking around, I found three different solutions for this problem:
  1. Modifying your powershell.exe.config;
  2. Modifying your request in order to avoid it stopping if your url is invalid in .NET
  3. Modifying your request in order to avoid it stopping if your url is invalid in PowerShell.
Let's review each of them and understand a little more about the problem.

    Solution 1 - Modifying powershell.exe.config

    This solution will apply to all PowerShell requests so use with caution. Also, this solution is not portable so, if you plan to run this script on a machine you don't have admin access to, this solution will probably not work.
    <system.net>
    <settings>
    <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
    </system.net>

    Solution 2 - Modifying your request in .NET

    To modify your request, have the code below before you actually run Invoke-WebRequest:
    $netAssembly = [Reflection.Assembly]::GetAssembly([System.Net.Configuration.SettingsSection])

    if($netAssembly)
    {
        $bindingFlags = [Reflection.BindingFlags] "Static,GetProperty,NonPublic"
        $settingsType = $netAssembly.GetType("System.Net.Configuration.SettingsSectionInternal")

        $instance = $settingsType.InvokeMember("Section", $bindingFlags, $null, $null, @())

        if($instance)
        {
            $bindingFlags = "NonPublic","Instance"
            $useUnsafeHeaderParsingField = $settingsType.GetField("useUnsafeHeaderParsing", $bindingFlags)

            if($useUnsafeHeaderParsingField)
            {
              $useUnsafeHeaderParsingField.SetValue($instance, $true)
            }
        }
    }

    Solution 3 - Modifying your request in PowerShell

    This is probably the simplest. Just run the line below:
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }

    Conclusion

    On this post we reviewed three different ways to resolve a problem in PowerShell. Don't know PowerShell yet? I would urge you to take a look and learn it (even if just the basics). PowerShell is a powerful tool used extensively in devops on Windows, Azure and Linux.

    See Also

    About the Author

    Bruno Hildenbrand