Restore NuGet Packages the Right Way

The Infamous Right Click to Enable NuGet Package Restore

Recently engaged in a conversation about NuGet and one of the developers suggested to me "Did you right click the solution to enable NuGet restore?" I was a little shock and unease as this is a very very old and obsoleted way of using NuGet and is not relevant in today's code of practice.

Let's learn the right way together!

NuGet Team documented 3 ways to restore packages.

1. Automatic Package Restore in Visual Studio
2. Command-Line Package Restore
3. MSBuild-Integrated Package Restore

As the NuGet Team explained.

"Prior to NuGet 2.7, an MSBuild-Integrated Package Restore approach was used and promoted. While this approach is still available, the NuGet team suggests using the Automatic Package Restore and Command-Line Package Restore instead."

Or what other people twitted.

"Every Time someone enables #nuget package restore on a solution, a kitten dies. Learn the new workflow!"

Verdict

What is the best practice? Automatic Package Restore is the number one recommended method. You may however find yourself using CLI Packge Restore if you are building a CI server which is not so bad. The worst possible scenario is you are still doing "Right Click to Enable NuGet Package Restore". Say hello to 2015 :)

TFS - Undo a Resolve Conflict During a Merge

Scope

Merge from projA to projB

Our IDE is Visual Studio 2013 and we use Visual Studio Online TFS as our repository.

As our projects grow in omni-direction with developments going on in multiple branches in TFS, I was trying to perform a merge between 2 projects and had some problems in trying to undo resolved conflicts. After I resolved the conflicts and before I commit any changes, there is no option for me to undo any resolved conflicts.

Furthermore, I have also tried the following and none worked for me. Visual Studio still assumes conflicts are resolved even though I did not check in anything.

• Undo Pending Changes then Merge again. 
• Delete the working folder, Get Latest then Merge again.
• Use a different version of Visual Studio then Merge.
• Shelve changes and Merge again.
• Delete the working folder. Create a new Workspace with different local folder mapping.
• Repair (reinstall) Visual Studio.
• Login with a different account on a different machine.

Solution

After learning that a different login and machine would not solve my problem, I know I am now in serious troubles. It doesn't make much sense that the conflict resolution is recorded anywhere else outside of my computer without me check-in anything, but now it seems the only logical way to think it is happening.

Instead of merging from projA to projB again, I now made a clone of projB by branch out projB to projB-Clone.

I then merge from projA to projB-Clone and I am now getting my Resolve Conflicts screen with x number of conflicts pending my action. After resolving my conflicts, I now need to commit my changes to projB-Clone.

In our projB-Clone, we have all the merged code from projA after the previous merge, we are now ready to merge this changes to projB. As anticipated, there should not be any conflicts, we are literally just copying / replacing files from projB-Clone to projB.

Finally I will merge projA to projB once more to check if they are identical and no conflicts. From this point, we have completed our original attempt of merging projA to projB and it is now safe to delete projB-Clone.

Merge from projA to projB via projB-Clone

Thoughts

It is an unresolved mystery why TFS records conflict results on the server where there were no check-ins or commits. I never had similar issues in other file repository like SVN. The 4 way operations to work around an undo resolve conflicts button? Certainly not appreciated.

MSBuild Error: Task could not find "sgen.exe" using the SdkToolsPath

Scope

I am getting an error when trying to build in release mode for one of my project. The error looks like this in Visual Studio 2012.

Task could not find "sgen.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed




Step In

Search around on the internet, it appears that sgen.exe is an XML Serializer Generator Tool (MSDN). It appears to me that I have 2 solutions.

Solutions

Disable "Generate serialization assembly"

If we turn off "Generate serialization assembly", then the compiler will not be looking for sgen.exe to precompile the serialization assembly.

Locate sgen.exe

A better solution would be fix the sgen.exe so that VS can find it.

At an attempt to locate this sgen.exe for VS, I tried to download and install the following.

• Microsoft Visual Studio 2012 SDK
• Microsoft .NET Framework 4 (Web Installer)
• Microsoft .NET Framework 4.5

Unfortunately, none of the above works except the below.

• Windows Software Development Kit (SDK) for Windows 8 

The v8.0A in the error message was a good hint of something about Windows 8

Conclusion

Finally, able to deploy from my machine in release mode for now. Until next time, I am sure I will run into similar issue again when building a continuous integration process and this article should come into handy.

Visual Studio Styles that visually works for MVC

When we talk about visual studio styles, I think everyone would have downloaded and used son-of-obsidian before. Me too, but once I started working with MVC, this popular style seems to have a drawback when highlighting text in the view (.cshtml). I have tried a few and finally settle with this.

http://studiostyl.es/schemes/dark-bliss

The highlighted color is actually distinctive from the background. Give it a try if you were stuck with highlight / background color just like me.