Remove All Nugets From All Projects

This may never be used in your usual conditions, however, I found it to be useful at least once: NuGet packages got messed up after some merges, with different versions in different projects. So I wrote a one-liner to remove all the packages from all the projects in the solution.

All you have to do is paste this snippet into the Package Manager Console.

Get-Project -All | %{ $projectName = $_.ProjectName; foreach($package in Get-Package -ProjectName $projectName) { Uninstall-Package -ProjectName $projectName -Id $package.Id -Force }}

All thanks to this reference.

Let's ask together for better Visual Studio support for Git

Ugh, three times already! I'm using Visual Studio with Git and for the third time I've pushed some changes at work, only to pull those at home and find out that a few files are missing from the repo. What is that?

When Microsoft announced that Visual Studio would support Git and, what's more, Visual Studio Online (their "cloud" TFS, not Visual Studio) would have Git as well as the old, SourceSafe engine, I was thrilled. What a wonder: the magic tooling that only Microsoft is ever able to give us, and a modern repository, and a distributed one at that.

About two years later and I finally did a deep dive on that support and I must say, I'm pretty disappointed. I always thought the interface clumsy and, in the past, I reverted to using SourceTree, which is still my favorite Git client. But right now I'm working on a client environment and I have no choice but to use their machine. And this also means not being able to install anything, which means - you guessed! - using only Visual Studio support for this.

Now, besides the clumsy interface, I've realized that the support is incomplete, missing a number of features from Git, and even worse, the bad support can lead to mistakes as the one on the first paragraph:

• Visual Studio allows committing with untracked files. This is my major peeve, as you all can see in the first paragraph. SourceTree simply enforces that either we ignore or push the file. I think it makes a lot of sense, and avoid problems such as the one I suffered.
• Better history view. Checking a file history through Visual Studio is doable, but not fine. I know that this isn't something easy to do through Git's command line as well, but VS can do better.
• Better Navigation. Oh my god! Clicking a dropdown to choose whether I want to see changes, branches or  whatever... I think this can be much improved. Why do we have to have a small screen with the complex navigation, when we can have a full screen like a real tool? Yeah, that would break VS look 'n feel, but what of it? What is more important?

I'll keep myself to those three points. There are other places where it could be better, of course, but those three would make me very happy.

Embedding DLL's

I've faced this problem before, and ended up with the same solution: I have to deploy a solution that is composed of more than one file, usually an exe and a set of DLL's.

But the deployment process expects only a single file. With Java, this is simple; Maven can pack every dependency together and a single jar file is generated for your application. But how we solve this with .NET and it's multiple DLL nature?

 MSFT Research created a tool for that, called ILMerge.

However, this tool has shortcomings, such as it's unability to work with WPF. Now, what I've done in the past (when I needed to include a native DLL to do some interop, actually) is much more like the solution presented here. In short, all you do is embed the DLL's as resources in your main assembly (be it a executable or library), and add an event handler to the AssemblyResolve property of the current appdomain

AppDomain.CurrentDomain.AssemblyResolve += (sender, args) => {

   String resourceName = "AssemblyLoadingAndReflection." + new AssemblyName(args.Name).Name + ".dll";

   using (var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName)) 
   {
      Byte[] assemblyData = new Byte[stream.Length];
      stream.Read(assemblyData, 0, assemblyData.Length);
      return Assembly.Load(assemblyData);
   }
}

This will result in the appdomain loading the embedded DLL as resources. The code above can be adapted to even load executables if necessary.

Linux “Touch” in Windows

Another quick reference:

copy /b filename.ext +,,

The command above will “touch” a file (change its modified time).
Hope it’s useful.

Kill a pending session on Oracle

I'm no DBA... so sometimes the simplest thing may be hard. I'm currently using Oracle in one of my projects, and I been having trouble with pending sessions / transactions. So I had to discover how to kill them. I found this link, which I reproduce partially here for the sake of preserving the information.

Identifying the locks:

SELECT  
 l.inst_id,  
 SUBSTR(l.oracle_username,1,8) ora_user,   
 SUBSTR(l.session_id,1,3) sid,  
 S.serial#,  
 SUBSTR(o.owner||'.'||o.OBJECT_NAME,1,40) object, 
 p.spid os_pid,  
 DECODE(l.locked_mode,
  0,'NONE',  
  1,'NULL',  
  2,'ROW SHARE',  
  3,'ROW EXCLUSIVE',  
  4,'SHARE',  
  5,'SHARE ROW EXCLUSIVE',  
  6,'EXCLUSIVE',  
  NULL) lock_mode  
FROM    
 sys.gv_$locked_object l, 
 dba_objects o, 
 sys.gv_$session s, 
 sys.gv_$process p  
WHERE
 l.OBJECT_ID = O.OBJECT_ID  
  AND     l.inst_id = s.inst_id  
  AND     l.session_id = s.sid  
  AND     s.inst_id = p.inst_id  
  AND     s.paddr = p.addr(+)  
ORDER BY l.inst_id

Killing the session:

The SID and the SERIAL# fields can then be used to issue the kill command:

ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE