locked
Embedding Fonts causes SLOW VS 2010 Build RRS feed

  • Question

  • After upgrading our Solution to VS2010 we found that VS would take 60 seconds before it appeared to actually build our project.

    With VS 2008 our Project would build in 3 seconds.

    I finally discovered that when we use Expression Blend 3/4 to embed a font into our Project, it slows down the build in VS 2010.

    Has anyone got a solution to fix this?  We need 20 fonts embedded in our WPF application, and I CANNOT HANDLE waiting 60 seconds everytime I build my application.

    Thursday, September 8, 2011 2:42 PM

All replies

  • Blend and VS both use the same build system, msbuild. The build in VS and Blend are essentially the exact same thing. When you embed fonts, you add a build task that has to process each font. That is the source of the slowdown.

    I don't know if it will work, but you might be able to put the fonts into a separate assembly that doesn't get rebuilt on every build. I haven't tested that so I don't know if it will work. Other solutions would be to conditionally not embed the fonts while doing development, and only for builds you need the fonts embedded actually include the fonts into the built assembly. Are any of the fonts extremely large?

     

     

    Thursday, September 8, 2011 3:19 PM
    Moderator
  • Do you know what changed between VS 2008 and VS 2010?  Prior to converting to VS 2010 the embedded fonts were never an issue when compiling.  Only after switching to VS 2010 did this become a pre-build slow down.

    Process Monitor shows the devenv.exe constantly touching the .ttf files prior to ultimately beginning the build.

    If we decide to put them into a seperate DLL and reference that dll from our project, does that now preclude us from being able to use the checkbox in Blend that says embed this font?  Do you have any suggestions that would allow us to continue to use Blend to determine when to embed a font?

    Thanks.

    Friday, September 16, 2011 2:39 PM
  • I know it's been a while, but here is how I solved a related problem last year - for me the issue wasn't just a slow build, but an always-rebuilding assembly (which forces rebuild of dependencies, etc) even if no changes were made. It might help you out too because certain types of rebuilds get sped up a lot. If you're on winXP they might help with memory issues because font-embed task seems to be a doozy in that regard. If you're like me and like to build on the command line, it will avoid the 'current sources are never loaded' issue.

    Read the details here:

    http://stackoverflow.com/questions/3765391/embedding-fonts-forces-silverlight-project-to-always-rebuild

    Basically, I hacked up the relevant MSBUILD target to limit unnessesary font embedding, which always forced a rebuild. It's probably not a good idea to use if you're doing some fancy trickery with the character sets, but works quite well for me.

    I never really got any feedback from anyone on the problem, or its solution, so if I'm doing something stupid please write (here or on SO).

    Wednesday, October 5, 2011 7:33 AM