When and how often does ""ResolveAssemblyReference"" get executed during IDE scenarios?

Typically, it is the ""ResolveReferences"" target that is being invoked, since it is usually the case that all types of references need to be resolved, not just one particular kind of reference. The ""ResolveReferences"" target depends on several other targets like ""ResolveAssemblyReferences, ResolveCOMReferences"", etc. It is the ""ResolveAssemblyReferences"" target that invokes the ""ResolveAssemblyReference"" task.

So ... given this, the ""ResolveReferences"" target gets invoked under the following circumstances:
* whenever the IDE's compiler needs to be re-initialized at design-time. This occurs at project-load time, as well as any time thereafter when anything in the project file changes (even if the changes haven't been saved to disk yet). This includes items being added/moved/renamed/deleted from the project, references being added/removed from the project, or even something as simple as a change in the value of a project property.
* whenever an up-to-check is requested. Up-to-date checks are requested whenever the user attempts a build (which could be as a result of F5), such that if the up-to-date check returns "true, project is up-to-date", then the build is skipped. However, up-to-date checks are also requested during several design-time scenarios in order to support design-time expression evaluation (DTEE).
* during a build. During a real build, we of course have to re-initialize the IDE compiler to make sure we're feeding it all the right stuff, and so as a result, we run ""ResolveReferences"" to ensure that all references are fully up-to-date and resolved.

""In addition ... whenever a reference is added through the IDE, the project system calls the ResolveAssemblyReferences target specifically in order to provide the resolved path to the newly added reference. This is so that the project system can report this information to clients of the project system.""

""All of this seems like a lot of calls to the ResolveAssemblyReference task, and it is.

In Beta 2, we should look to see if we can reduce the number of calls in order to get some perf benefit. But in the meantime, it should be noted that the ResolveAssemblyReference task does quite a bit of caching so that it never tries to resolve the same reference twice, or crack its dependencies twice. There is an on-disk cache file called ResolveAssemblyReference.cache, which persists across IDE instances or command-line builds, but is per-project. In addition, there is also an in-memory per-process cache which spans projects, so that a SLN with 100 projects open in the IDE can avoid resolving the same reference (like System.dll) once per project.""