Raman Zhylich

If for some reason during merge, rename or move you lost history in TFS don't turn upset. There is still an easy way to restore history. The below call will merge only history and will not modify the contents of the files. call tf merge /version:295449 /baseless /recursive /discard "$/MyProject/SourceBranch" "$/MyProject/TargetBranch"

I've found a bug in fast up-to-date check and decided to report it to authors. I hope it will influence Visual Studio team and they will revisit U2DCheck design and provide some level of extensibility to developers. https://connect.microsoft.com/VisualStudio/feedback/details/2468519

Fast up-to-date check was created in an attempt to mitigate performance issues with incremental builds in MSBUILD. Indeed if you have many projects it would take considerable amount of time to evaluate each of them and check timestamps on all input and output files. Instead Microsoft decided to implement a simplified version of these checks that would run faster without involving MSBUILD engine. As a result this "feature" only works with "native" targets and if you have any kind of customization where external inputs or outputs are used then you'll have "misfires" sometimes. Below is some information I was able to figure out that can help you mitigate those issues. It's based on my own investigation therefore it may be not accurate enough. At least this is the most complete description that you'll find on the web. It will help you a lot in troubleshooting if you enable up-to-date check logging. Go to HKEY_CURRENT_USER\Software\Microsoft\Visua...

NPM 3 works significantly slower than its preceding version. Bad news is that development team is not going to do anything about it. https://github.com/npm/npm/issues/8826 I've implemented an alternative cache based on junction point that works much faster. Instead of restoring each package it mirrors the whole node_modules folder from cache using junctions. This approach gave me a noticeable performance improvement. Restoring from cache happens almost instantaneously.

You can get this message if you are using tfs proxy. The source control proxy 'xxxxxxxxx' is not responding, so the request will be sent to the main server. Please verify your settings. Additional information: TF30063: You are not authorized to access Microsoft-IIS/7.5. ---- Summary: 0 conflicts, 1 warnings, 0 errors ---- Solution: Go to Control Panel\Credential Manager and add your tfs credentials for proxy server.

I've been struggling for a long time with npm because it keeps all downloaded packages and its dependencies in a deep tree-like structure and therefore exceeds allowed 260 characters restriction for paths. As a result most of the tooling doesn't work properly. MSBUILD wildcard search is failing without visible symptoms when long paths exist. CruiseControl cannot cleanup workspace because of long paths. TFS is failing to compare files for the same reason. I really can't understand how such an issue could exist in a world-known package manager. Fortunately, I've got to know that npm@3 is coming where this problem is fixed. In this release npm flattens folder-structure eliminating long paths. I've tested this and it really works. I'm happy this problem will be solved at last soon.

One of the features of Windows MSI is that it can determine what version of the product is installed already and upgrade it if necessary. It uses unique product code guid to identify your product among all installed programs. This implies that product can be installed only once. But what if you have a requirement to install the same product several times on the same machine? Microsoft suggests that you use instance transforms to do that. But this means that for each installation you need to ship a separate instance transform which is not suitable in my case. I came up with the following script that modifies msi product code and allows you to install it as many times as you want. Each installation is identified by a unique instance name. You specify it as an Instance parameter to the powershell script below. wirunsql.vbs and wisuminf.vbs are part of Windows SDK:  https://www.microsoft.com/en-us/download/details.aspx?id=3138