Question: There are a number of post in relation to Visual Studio building projects when not necessary. However, none seem to cover this particular issue.

I'm running Visual Studio 2012 Professional Update 4.

In my solution, I have a unit test project that has a project reference to a BizTalk Transforms project. This in-turn has a project reference to a BizTalk schemas project.

Every time I choose to run a unit test, the whole solution is built, even though no changes have been made.

The first line displayed in the build window is as follows:

> 
> Input file
>  'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\FFF.Enterprise.WareHouse.Schemas.btproj.user'
>  is modified after output file
>  'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\bin\Release\FFF.Enterprise.WareHouse.Schemas.pdb'.
> 
> 
> 

Note: it seems to be the **.user** file that's causing the rebuild.
Does anyone know how to prevent this? Strange but I only seem to be getting the problem with BizTalk proj files. I am seeing this behavior across multiple solutions but the problem file is always identified as a btproj.user.

This screencast illustrates the problem: [screencast link](http://biztalkers.com/video/build-before-test.mp4)

Answer: 
I am going to speculate here a bit, and then a comment about your design.

First, when you create an index on key which has an array on a value you create a record for each element of the array:

> 
> To index a field that holds an array value, MongoDB creates an index
> key for each element in the array.
> 
> 
> 

This is from [MongoDB own documentation about indecies](https://docs.mongodb.org/manual/core/index-multikey/).

So, if your typical record more than a hand full of categories and you have 7 million records,
your index is huge, and it will also take time to scan the index itself to find that the index does not contain what you are looking for. It is still
faster than a collection scan, but it darn slow compared to how fast it takes to find an existing record.

Now, let me comment about your schema design. This is a matter of style so feel free to ignore this part.

You have a record which might be in 17 categories. That is a bit overwhelming, and over abusing the term `category`. A category is a specific
division, a way to quickly associate a thing with a group of things. What is a thing that belong to so many groups?
Let's take for example your records `Cafe Ne`. I assume in the real world - and please remember, programming and applications are at best when the solve real world problems - Cafe Ne, is either a restaurant, a caffe, a jazz bar,
a dinner. It's for sure not a garage (unless, cafe means cars in a language I don't know). I can hardly imagine it's a bank or a dental clinic. I'd have to really make an effort, to find more than 10 meaningful categories, that users search a cafe by.

My point is, even though mongodb allows you to design things like that, it does not mean you have to. Try to narrow the number of categories you have and the ones you look for, and you will have much better performance.
As JohnnyHK suggested in comments, and Oz123 pointed to in his answer, the issue here appears to be an index that has grown so large that it fails to perform well as an index. I believe that in addition to the category expansion issue that has already been pointed out, the ordering of fields in your index creates trouble. Compound indexes are [built according to the order of fields](https://docs.mongodb.org/manual/core/index-compound/), and putting `name` after `categoriesIds` makes it more costly to query on `name`. 

It's clear that you need to tune your indexes. Exactly how you tune them depends on the types of queries that you are expecting to support. In particularly, I'm not sure if you'll see better performance from a compound index of `loc` and `name` or if you'll see better performance from individual indexes, one for `loc` and one for `name`. Mongo themselves are [a little vague](https://docs.mongodb.org/manual/core/index-intersection/#index-intersection-compound-indexes) on when it's best to use a compound index and when it's best to use individual indexes and rely on index intersection. 

My intuition says that individual indexes will perform better, but I'd test both scenarios. 

If you anticipate needing to query by category as well, without `name` or `loc` fields that could narrow the query down, it's probably best to create a separate `categoriesIds` index.