Add current Git commit to web.config on each build [.NET Core/ASP.NET Core]

-
*Docker service might eliminate the following technique's usability.

In this post, I am going to demonstrate a way to actually write the current commit of your version control module (I am using Git) into a location, let's say in your web.config.

One of the issue I have faced when managing multiple console apps., or even web projects is that it is not easy to keep track of the commit which the applications belong to. However, there is a simple technique to actually write the current commit of a specific branch into a location inside your project. The technique is the same regardless of the project type.

*I am talking about .NET based projects. Although I only tested this in .NET Core based projects, I am pretty sure it works almost the same in .NET Framework/ASP.NET MVC based projects.

The main idea is the utilize the build engine, MSBuild, to do something after building your application. The command execute a task could be derived in your .csproj file. You can define a task inside the Target element. A Target element will contain one or more tasks which will be executed in sequence. You could read more about this here, https://docs.microsoft.com/en-us/visualstudio/msbuild/target-element-msbuild?view=vs-2019.

The definition of task(s) is built on XML format, and you could imagine Target as the root element. The following represents the root of our task which will execute post-build.

<Target Name="PostBuild" AfterTargets="PostBuildEvent">

Next, we would like to define a variable which represents the string. In this case, we could use the PropertyGroup element. 


 














<PropertyGroup>
  <Head>abc</Head>
</PropertyGroup>
Subsequently, we could refer the Head tag as the variable using the dollar sign, $, which would then gives us the value 'abc'. However, we would like to have Head to give us the current commit ID. For that, we could use property function to tap into .NET library to access the method to read a file. For simplicity, I would read a file in the local .git folder which has the information about the commit information where my current head is pointing to. Since my .git  folder resides in the folder which is the parent of my .csproj folder, I would need to navigate to the parent folder, and access file which contains the commit ID of my develop branch.

<PropertyGroup>
  <Head>$([System.IO.File]::ReadAllText("..\.git\refs\heads\develop").Trim())</Head>
</PropertyGroup>

The final step involves defining the task to change the web.config. Since web.config is XML-formatted file, we could use something called XmlPoke  to perform the operation. Basically, this is just a task to find the correct tag to override in a XML schema. Let's say we have a tag called ID that we would like to override after every build event.

<configuration>
  <configSections>
    <section name="Commit" type="System.Configuration.SingleTagSectionHandler" />
  </configSections>
  <Commit>
    <ID>abca0db5de924808fd2aa5e02dd1ddadb2025817</ID>
  </Commit>
</configuration>

We need to define the Commit tag in configSections, or else you will have problem launching your ASP.NET application because the application cannot recognize Commit tag. The XmlPoke task is shown below. We are using the Query attribute to find the tag which the value we will override. 

<XmlPoke
  XmlInputPath="Web.config"
  Value="$(Head)"
  Query="/configuration/Commit/ID"
  />



So, this is a simple way to write a commit ID into your web.config on every build, the full XML task in the .csproj file is as follow.





<Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <PropertyGroup>
      <Head>$([System.IO.File]::ReadAllText("..\.git\refs\heads\develop").Trim())</Head>
    </PropertyGroup>

    <XmlPoke
      XmlInputPath="Web.config"
      Value="$(Head)"
      Query="/configuration/Commit/ID"
      />
</Target>


































Comments











Post a Comment























Popular posts from this blog









ASP.NET Core service locator pattern






-















There are many posts out there which specifically say that we should not use service locator pattern (unless necessary), which we would not be able to determine the dependencies during compile time because the dependencies are hidden. However, I am going to point out an issue in case if you need to use it, in the context of ASP.NET Core projects.   I have a class Foo , which will be bind to IFoo , and I will need to configure a named HttpClient for that class via the following extension,     services.AddHttpClient<IFoo, Foo>();   If we do the above, Foo will be treated as an object which is Singleton injected. In case you are not aware, we cannot inject services which has a smaller lifespan than the service itself. Hence, we cannot inject services which are transient or scoped into Foo . Here comes the problem, what should we do?   That's where service locator pattern comes to the rescue! There might be other way, but let's say we decide to use the service locator provide








Read more










Ways to perform eager loading via NHibernate






-















By default we know that lazy loading is enabled in NHibernate. So, let's say if we decide to keep the default, how do we enable eager loading with NHibernate?   There are 2 ways to do that (there are more, but I will mention 2 that you will commonly see):   1.  Query<Entity>().Fetch(x => x.ClassA).Fetch(x => x.ClassB);   2. var tempQuery  =  Query<Entity>().Fetch(x => x.ClassA).ToFuture();       Query<Entity>(). Fetch(x => x.ClassB).ToFuture();       var entityList =  tempQuery   .ToList();   Do note that Fetch is used to fetch reference, while FetchMany is used to fetch collection. If you are wondering what is the difference between 1 and 2, it is the use of ToFuture to split the SQL statement to multiple queries.   The problem with multiple Fetch  in a single LINQ query is that it would result in Cartesian product of the main object, in this case, Entity  . Hence, it is not recommended to use multiple Fetch in a single query, but rather use method 2.








Read more










Caching and generic query using NHibernate [.NET Core]






-















One of the important aspects in API design is to reduce the number of fetch request to database. NHibernate provides 2 levels of caching, with the first level cache persist through a session only, while the 2nd level cache persists across multiple sessions.   The second level cache can be implemented by installing the NuGet package of NHibernate.Caches.SysCache . Then, it involves some configuration setup to utilize the cache feature. However, there is an alternative way that exists in .NET Core which we could use to build a simpler cache.   The caching that we could use is IMemoryCache . Firstly, we could setup the cache during  ConfigureServices .    public  void  ConfigureServices(IServiceCollection services) {    services.AddMemoryCache(); }     Then, assuming we want to retrieve all the records from a table called DailySales , and we want to keep the records in the cache for 1 minute, we could do the following.       private  readonly  IMemoryCache cache;  public  DBHelper(IMemory








Read more