I’m having an odd issue with Expression Blend 4. I’ve been using Blend 4 in conjunction with Visual Studio 2010 for quite a while without incident (beyond the ultra-frequent crashes). Now our graphics designer wants to start using Blend to do some touch-up work.
We were able to get Blend to compile the solution on his computer. Unfortunately, when we try to open any XAML file, we get errors from the designer where resources included through the merged resource dictionary and attached properties are not recognized. Basically, it’s as though the build artifacts aren’t seen even though Blend is compiling the solution with no errors.
The only oddity in our setup is that our solution contains multiple build configurations, and you cannot change your build configuration in Blend.
Why do you suppose Blend’s designer is failing to load the files that it built?
In figuring out how Blend 4 builds Visual Studio projects/solutions, I found out why our graphics designer’s copy of Blend was not working properly and fixed the problem. The multiple build configurations that we had set up were to blame. Here’s the specifics of what I found out and a list of warnings to anyone else using multiple build configurations, Blend 4, and Visual Studio 2010.
Warning 1: Blend does not allow you to choose a build configuration.
In Visual Studio, when you build, you are always building with a specific build configuration. This setting can be changed. Blend doesn’t appear to have the ability to change the build configuration setting anywhere in its UI. Instead, it uses its own heuristics for selecting which build configuration to use.
Warning 2: Blend does not use the same logic for selecting a build configuration when building as it does when designing.
This is what was causing issues for us. It seems that Blend has two different ways to choose a build configuration. When you compile, it uses the logic in the .csproj files for selecting a default build configuration (see warning 3). The designer, however, looks to the solution file for which build configuration’s output directory it should use to resolve assembly references (see warning 4). So although Blend was compiling alright, the designer was not looking at the compiled files but at an empty bin directory it created.
Warning 3: Blend and Visual Studio do not handle default build configurations the same way.
At the top of .csproj files, there’s a property group that specifies which build configuration to use when one is not specified when running csc.exe. Visual Studio does not seem to modify this data, probably because it doesn’t need it given that it always uses a defined build configuration. We had removed the default Debug and Release configurations and made our own DebugWindows, ReleaseWindows, DebugMac, and ReleaseMac configurations, but the project files still said to use “Debug” when no configuration is specified. Blend 4 runs csc.exe with no build configuration, so the defaulting logic is used. Therefore, I had to manually fix up the .csproj files.
Warning 4: Visual Studio does not allow you to order your solution’s build configurations, and the ordering is relevant to Blend.
Contrary to how Blend selects build configurations when compiling, Blend’s designer seems to use the first solution configuration in a solution file to associate projects with a build configuration. The designer then looks to the output directory for that configuration for its assemblies. In other words, if there’s a mismatch between the .csproj build configuration defaults and the first-solution-configuration’s settings, the designer will not see your classes, merged resource dictionaries, etc, even if you built the project.
Whichever solution configuration is first cannot be changed through Visual Studio. For us to fix where the designer looked for build artifacts, we had to reorder the solution configurations manually in the .sln file.