3

I'm on a BizTalk 2013 solution and I'm trying to grow into automated testing. However, when I try to run my tests after changing only the test project, or even just run the tests after changing nothing anywhere, I'm stuck building the same amount of projects that I build when I invoke a full rebuild on the project being tested. This eats up an enormous amount of time, and it's a death sentence for my ability to sell future investments into this type of thing.

Is this is a known deficiency with BizTalk, or with its interaction with MSBuild? Is it a known pitfall that I can repair on my end?

EDIT: After reviewing the "possible duplicate" thread, I believe this question to be similar, but distinct. The explanation from the thread highlights the mechanics by which MSBuild determines that a rebuild is necessary, but MSBuild is widely-used technology across all projects in Visual Studio and can differ significantly by project type based on that project type's specific targets import. I've edited the question title to reflect that I want to learn how to prevent this for BizTalk solutions rather than simply asking why it's happening (although knowing why is always helpful).

bwerks
  • 8,651
  • 14
  • 68
  • 100
  • 2
    Possible duplicate of [Unnecessary project rebuilds when unit testing in Visual Studio](http://stackoverflow.com/questions/23062116/unnecessary-project-rebuilds-when-unit-testing-in-visual-studio) It's not just biztalk solutions either. – Dijkgraaf Mar 10 '16 at 03:01
  • I had initially agreed with the duplicate issue, but this one does seem to be a little more specific to BizTalk projects. – Dan Field Mar 10 '16 at 19:19
  • Related question with no accepted answer http://stackoverflow.com/questions/33870271/vs-2012-user-file-causes-unnecessary-builds/34147282#34147282 – Dijkgraaf Mar 16 '16 at 02:28

3 Answers3

3

So, what you're seeing is not a problem with BizTalk (because BizTalk is perfect and wonderful and never has any problems ever...:).

It's actually a behavior of Visual Studio. To note, BizTalk Projects are just specialized c# Projects.

The best workaround, which I do all the time, is to uncheck the Build and Deploy options for Projects I'm not actively working with in the Solution Configuration. If the Project is not checked for Build, it will not build even when you choose Rebuild Solution.

Johns-305
  • 10,908
  • 12
  • 21
  • I had actually tried something similar to this in the past by unloading projects that had already been built, but sadly VS then complained about missing reference. I'll give this a shot though! I think this will eventually bite someone in my organization since changing those settings will cause pending changes against the .sln file, but maybe with good enough communication we can still benefit from it. – bwerks Mar 10 '16 at 19:14
2

One possible solution would be to reference not the projects, but the DLL files which are the result of the same - already compiled and built - projects.

This way, when building your test project, it would be built against these existing assemblies and hence would not take the time to rebuild those.

You have to make sure however that these DLLs are updated whenever the project behind them also updates. You could do this by rebuilding them, whenever necessary, in a separate Visual Studio instance.

It takes some practice and thinking to make sure you are building against the latest version, but it WILL save you a lot of time.

zurebe-pieter
  • 3,246
  • 21
  • 38
  • Practically speaking, even when using ProjectReference I find a lot of situations wherein VS yells at me about mismatched dlls/codefiles when I debug into a unit test, so I'm already used to proactively building my product code prior to testing anyway. This solution might be a great fit! – bwerks Mar 10 '16 at 19:18
2

I've noticed this as well. Turning on diagnostic output on MSBuild, it turned out that the project settings .user files were being modified after the .pdb files. I've tried several ways of resolving this, including changing the modify date on the pdb file, setting the .user file to readonly, removing (renaming) the .user file, etc.

Unfortunately, the build task for BizTalk will overwrite/recreate/create new .user file after every build, and I haven't come up with a way to convince MSBuild that that it can just ignore the .user file being created as new. Due to that, I'd go with one of the other suggestions here.

Even creating an exclusive lock on the file so that MSBuild can't update it causes a rebuild, since then MSBuild thinks the build is dirty ("Project 'Schemas' is not up to date. Project dirty in MSBuild.")

Dan Field
  • 20,885
  • 5
  • 55
  • 71
  • Nice, this is the exact context I was looking for. Thanks for the insight! – bwerks Mar 10 '16 at 19:15
  • Tried to remove .user-file on pre- and post-build events, but it creates a new file before it starts building, then checks if somthing was changed after last build, and finds that the .user-file was created afterwords...neat. I guess a project template update is needed? – JERKER Feb 14 '19 at 10:44