Friday, January 19, 2018

CommonAssemblyInfo

I'm writing this post since I posted this on Twitter, and within half an hour, was asked to share my knowledge:


In Visual Studio, there's a little known feature that lets you add files as links to a project. Using this trick, we can also ease maintenance slightly by having a CommonAssemblyInfo.cs file where common attributes across the assemblies in a solution can be applied, but maintained in a single file.

Here is the sample demo application to show the steps one normally goes through. We have an existing command line utility to calculate tax based on an entered amount and tax rate. Quite simple.


In the Properties folder there is an AssemblyInfo.cs file listing the various attributes applied to the assembly.


This isn't always set up as expected, because most people forget to look at this file. One thing that stands out for example is the Company and Copyright information is defaulted sometimes to Microsoft or some other vendor based on the system settings. This may be undesirable, and so we can update these settings.


See some links at the bottom of this page for more info on these attributes.



You can see these are shown in the properties on the executable that is built.

Maybe we go back to look at our application and want to separate out the domain aspects of the console application, perhaps because in future we may want to share that with a web application frontend. The first step one would do is creating a new project and moving the classes around, fixing references, etc.


But you'll notice that most of these attributes are the same. The only two that maybe would be different are actually just the title of the assembly and the Guid it uses. If we rename things someday, we'd have to update at least two files (maybe we rename CommonAssemblyInfoDemo to something more useful, for example).

The first thing I usually do when creating a solution with more than one project, is first creating a file called CommonAssemblyInfo.cs that lives in the same directory as the solution file (CommonAssemblyInfoDemo.sln). This is usually done outside of Visual Studio, and then using Visual Studio to add the existing item to the solution, to make it easier to edit. I also setup solution folders that are numbered to keep things nicely organised.


You'll notice that only the common attributes are left in this file. But we still need to incorporate it into the other projects.

To do this, we also need to add it as an existing item to each project, however, there is a trick - we need to add it as a link.




You'll notice in the Solution Explorer that the icon of the file has a link symbol in it, to indicate it's just a reference to an existing file, so that all links refer to the same file.

Now we just update each projects AssemblyInfo to just include the information related specifically to that project.


If we need to update the AssemblyVersion across the entire solution, it's now a simple matter of just updating the CommonAssemblyInfo file to do this, instead of going through each project and remembering to update each one.

Hope this helped someone, the extra effort when setting up a new project can sometimes save time in the future.

For example, if we had a continuous integration build, and we just wanted to update the version number across all these artifacts based on some number set in our CI system, we could just update the CommonAssemblyInfo file before we run the solution through the build.

Links




Thursday, November 30, 2017

bash startup files and aliases

Today I hosted a Beer and Tech session at Entelect on Automating Database Deployments (with Flyway).

During the session, I was using the Bash terminal to edit files or run Flyway, and interacting with git quite a bit - as we all know, using git on the command line is the best way to do so ;D

After the session, a colleague asked me how I created shortcuts for certain commands, and I explained to him how Bash supports aliases and that these can be loaded by a startup file. There are various startup files, but I tend to use ~/.bash_profile and not ~/.bashrc. Here are some of the shortcuts I currently have setup:

alias cls='clear'
alias l='ls -Al'
alias ..='cd ..'

alias gf='git fetch --prune'
alias gl='git log --name-status --abbrev-commit'
alias grh='git reset --hard'
alias gs='git status'

And so on. If you modify the file, you have to re-load these into the current session, or restart a new terminal session. To reload the file, you can just do the following:

$ . ~/.bash_profile

Hope this helped someone :)

Thursday, July 20, 2017

git - exclude files in a diff

In some scenarios you might have a build server that doesn't have access to the Internet, in which case if you're working with something like npm, you might need to commit your node_modules folder to the git repository to get stuff to work.

Of course, it might be better to setup your own artifact repository such as Nexus on an internal network for these dependencies, BUT, I didn't have that! :D The node_modules are included as part of a commit.

Having to do a code review of a pull request can be tricky because of this, due to more than 10,000 files being in the commit, of which only 40 are actual source files of interest. We're using TFS 2017 which has a nice web interface for doing this, however it only supports showing 1000 files at a time.

So back to the best way to use git: the command line :)

To exclude the node_modules from the diff was as simple as doing the below:

$ git diff master develop -- . ':!node_modules'

Of course, I used difftool because I prefer WinMerge but it works the same.

Wednesday, April 19, 2017

Finding currently executing queries and parameters

If you've worked with an Object Relational Mapper (ORM) such as Hibernate, NHibernate, Entity Framework, etc., then you'll know these sometimes convert your queries into parameterized queries that can become quite beastly.

Trying to debug it means either profiling the database to see what queries are executing, and then seeing the query and values from there, or if you can't profile it, maybe selecting from some system tables to do a similar thing.

This snippet below (thanks again StackOverflow) will give you some nice details about the queries on a database, including an XML query plan that contains the parameters that were used when generating the query plan. It can be useful in diagnosing slow queries:

select * 
from sys.dm_exec_requests r 
cross apply sys.dm_exec_query_plan(plan_handle) as qp
cross apply sys.dm_exec_sql_text(r.sql_handle) 
where r.database_id = DB_ID('<dbname>') 

Thursday, March 23, 2017

tail on Windows with PowerShell

One of the well known Unix/Linux commands is tail, which gets the tail of a file, meaning the end of a file and prints it out to the output stream.

I used to try find nice programs for this, including Baretail which has some very nice features like colouring lines in that match certain patterns etc.

But if you just want a simple, and now built into Windows solution, just use PowerShell:

Get-Content -Tail 10 filename.txt

This will show the last 10 lines of the file. You can even follow the tail, or watch it for changes, as below:

gc -Tail 10 -Wait filename.txt

Another nice thing you can do is then pipe this into Select-String to filter the output:

gc -Tail 10 -Wait filename.txt | Select-String -Pattern somepattern