Whenever a new .NET assembly project is created in Visual Studio, a file named AssemblyInfo is created that contains attributes used to define the version of the assembly during compilation. Using assembly versions effectively enables various team members to identify deployed assemblies and helps troubleshoot problems that may occur in a particular environment (e.g. Development, Test, or Production).
When building the solution, there are two version numbers that need to be considered: the file version number and the .NET assembly version number. As part of the best practices, the AssemblyFileVersion attribute should be incremented automatically as part of the build process. It is therefore intended to uniquely identify a build. The AssemblyVersion attribute is the version that .NET uses when linking assemblies. In this blog post, we’ll learn how to use the build process to auto specify the AssemblyFileVersion and AssemblyInformationalVersion.
Continue reading “Auto assembly versioning in Visual Studio Team Services (or VSTS) build”
Visual Studio Team Services (VSTS) is popular tool of choice for various purposes where product is heavily dependent on Microsoft technologies like .NET, Azure, etc. It does lot of work such as Source code management, Building CI/CD pipelines, Package Management, Agile Issue tracking, etc. It is a cloud hosted service offering from Microsoft.
Hosted agent is a build agent that is provided by Microsoft for build and continuous integration purposes. However, you don’t have much control over the configuration of the hosted agent. It comes with most of tools you would normally require for building your source code. Now, when building PowerShell, it will come with latest version of PowerShell, so you can use built in package management cmdlets like Install-Module. Occasionally, you would need to install custom PowerShell modules such as SqlServer (Formerly known as SQLPS). Continue reading “Install PowerShell Modules on hosted agent in VSTS (Visual Studio Team Services)”
PowerShell core is the edition of PowerShell built on top of .NET Core. It is sometimes simplified to “CoreCLR”, though it technically includes CoreFX as well.
PowerShell Core is cross-platform, available on Windows, macOS, and Linux, thanks to the cross-platform nature of .NET Core. On PowerShell Core, $PSVersionTable.PSEdition is set to Core.
Do note that while PowerShell Core 6.0 is cross-platform, there is also a PowerShell Core 5.0/5.1 released exclusively as part of Nano Server. In this blog post, we’ll learn how to run PowerShell core in a docker container. Continue reading “Running PowerShell Core in a docker container”
I guess everyone knows that you can find current logged-in user’s profile path using variable $env:USERPROFILE, which is one of the built in environmental variables in PowerShell. However, you can also choose to navigate to current user’s profile path using ‘~’ (without single quotes). So for an example would be:
PS data [07/11/2017 09:58:00]> pwd
PS data [07/11/2017 09:58:01]> cd ~
PS mogoyal[07/11/2017 09:58:05]> pwd
However, unlike $env:userprofile, you can not use this in write-host to print out the value of the path.
This one is easy. Normally, a division operation would yield a floating number in PowerShell:
PS Data [07/04/2017 19:48:41]> 15/9
To round numbers, you can use the round() method from System.Math Class. Here’s an example:
PS Data [07/05/2017 10:32:05]> [Math]::Round(15/9)
Users can install and run multiple versions of the .NET Framework on their computers. When you develop or deploy your app, you might need to know which .NET Framework versions are installed on the user’s computer. Note that the .NET Framework consists of two main components, which are versioned separately:
- A set of assemblies, which are collections of types and resources that provide the functionality for your apps. The .NET Framework and assemblies share the same version number.
- The common language runtime (CLR), which manages and executes your app’s code. The CLR is identified by its own version number (see Versions and Dependencies). Continue reading “Determine .NET Framework versions installed using PowerShell”
When using windows PowerShell as REST client, you may encounter certificate invalid issues for various reasons. The most likely reason should be a self-signed certificate or a invalid common name certificate or sometimes not adding SAN names in the certificates. This may cause your script to break if it relies on fetching data from remote server when communicating on HTTPS.
To avoid SSL Certificate trust issues if using HTTPS, we can use below PowerShell function to help: Continue reading “Ignore self-signed certificates in PowerShell”