Visual Studio 2017 .csproj version patching in AppVeyor

After the debacle with project.json and .xproj, Microsoft settled on a simpler, more modern version of the old .csproj project system with Visual Studio 2017. One of the changes advanced users will notice when creating a new project in Visual Studio 2017, is the absence of AssemblyInfo.cs. You can add it back yourself, if you want to use some advanced options that aren’t available in .csproj, like the ability to make internal types visible to other assemblies, but by default, it’s gone.

This brings us to the topic of this post: the awesome AppVeyor Continuous Delivery service. One of the features offered by AppVeyor is so-called AssemblyInfo patching, which could change the version of your assembly to the one set in appveyor.yml, so the build number could be included, for example. However, with AssemblyInfo.cs no longer there, this feature, of course, won’t work and you’ll have to change your version number manually. Luckily, it’s pretty easy:

1
2
3
4
$path = (Get-Item .\Project\Project.csproj).FullName
$csproj = [xml](Get-Content $path)
$csproj.Project.PropertyGroup.Version = $Env:APPVEYOR_BUILD_VERSION
$csproj.Save($path)

Adding this PowerShell script to the before_build step will change the version number in the .csproj file to the version set in your appveyor.yml file, so your assemblies will have the correct version again.

Update

As Lee Campbell commented below, you can also use an MSBuild flag in your build command to set the version:

1
dotnet build /p:Version=$Env:APPVEYOR_BUILD_VERSION

It feels like this is the right solution for the problem, instead of fiddling around and changing files.

Thanks for reading! Enjoyed this post? Please share it with your friends using the buttons below! Have some questions? Comments can be found below too! And on a final note: grammar corrections are always welcome! English is not my primary language, but that’s not a reason to don’t learn how to use the language correctly.

Share Comments

Explore your Akavache cache on UWP

Akavache is an awesome library for almost every .NET desktop and mobile application platform to store both important user data and expiring local cache data. I’ve been using Akavache in a UWP app to cache results from a web service. In the Akavache README, the Akavache Explorer application is recommended for debugging the cache.

There are no binaries of the Akavache Explorer available for download, so you’ll have to compile it yourself. The README mentions Visual Studio 2010 is required (yes, this application is old), but it compiles just fine in Visual Studio 2017 RC. After starting the application, things get a little harder: the explorer needs a path to the cache file in order to work. However, you’ve probably never specified a location for that file in your code, so where can you find it?

Akavache Explorer asks for a path

The application data for a UWP app is stored in the <user>\AppData\Local\Packages\<package name> folder, which can be quickly found using the %LocalAppData%\Packages\<package name> shortcut. If you’re unsure what the name of your package is, you can look it up in the Package.appxmanifest file, on the Packaging tab.

The package name can be found in the Package.appxmanifest file

The different types of cache all have their own cache file:

  • LocalMachine: \LocalState\BlobCache\blobs.db
  • UserAccount: \RoamingState\BlobCache\userblobs.db
  • Secure: \RoamingState\SecretCache\secret.db

So in order to explore your LocalMachine cache, you’ll have to enter %LocalAppData%\Packages\<package name>\LocalState\BlobCache\blobs.db into the Path field of the Akavache Explorer. You’ll have to check the ‘Open as SQLite3 Cache’ option for every type of cache, the ‘Open as Encrypted Cache’ is for the Secure cache.

Notice that both the UserAccount and Secure caches are stored in the RoamingState folder, which means that these files are automatically synced across all Windows 10 devices logged in with the same Microsoft account. In other words, you shouldn’t use these for caching web requests, but they are great for storing settings and authentication.

If you know where to look, debugging your Akavache cache is a rather easy task.

Thanks for reading! Enjoyed this post? Please share it with your friends using the buttons below! Have some questions? Comments can be found below too! And on a final note: grammar corrections are always welcome! English is not my primary language, but that’s not a reason to don’t learn how to use the language correctly.

Share Comments