This project is read-only.


Dynamic compilation broken lately, at least with 1.6RC


See discussion with repro, also broken for Benedek and Nick:


sebastienros wrote Oct 26, 2012 at 10:16 PM

You are mentioning a repro, what post is it in the thread ?

DavidCornish wrote Oct 26, 2012 at 10:26 PM

I tried your instructions to add the 'foo' line to widgets module (from this week's meeting), and it didn't dynamically recompile. However, it did seem to pick up the change - I set a load of breakpoints in the DefaultVirtualPathMonitor and they hit when I made the change; it just didn't seem to actually load the change (which presumably would require an app restart which didn't happen). IIS express/VS2010/Win7x64.

sebastienros wrote Oct 27, 2012 at 12:42 AM

Could someone try to do the same thing with a 1.4 and if it works try to pinpoint which changeset made it fail. It sill works for me locally.

Piedone wrote Oct 27, 2012 at 11:27 PM

Started testing, all with completely new instances, using the WidgetFilter test, new clone (keep in mind for revision numbers).
  • Rev 6380 (95f0539354b2c71822610e30834b70ca58e6f601) WORKS. So apparently I was wrong about it being broken with 1.5.
Instead of searching binary I started next with the following changesets closer to 1.5 (I suspected the change creating the issue happened about two months ago, but definitely more than a month ago):
  • Rev 6402 (a560c383735a8e326e2642dce8fc11323fbf789f) WORKS
  • Rev 6491 (2b0669120473c68e6cf09735d54d02084b08f46e) DOESN'T WORK
  • Rev 6450 (2fab7efbb0f6eb9c519dfc278f56a11f18bc5887) DOESN'T WORK
  • Rev 6427 (e37c560e9af9e5b35893be6235b8e163b52d30e0) WORKS
  • Rev 6435 (5e2029f01380d291b36571e747c9ee42ca59e8a8) DOESN'T WORK
So it's suspicious that the MVC upgrade has broken dynamic compilation.

sebastienros wrote Oct 28, 2012 at 12:27 AM

Between 6427 and 6435 then, getting closer ...

sebastienros wrote Oct 28, 2012 at 12:31 AM

Wouldn't surprise me if MVC 4 was the culprit. Maybe something happened in MVC 3 which doesn't anymore. I am sure we can narrow the changeset further.

nightwolf226 wrote Oct 28, 2012 at 7:33 PM

Now we're in trouble I think, because Rev 6435 works for me (6469 doesn't).
Let's continue binary search and see what happens, I'm investigating now.

Piedone wrote Oct 28, 2012 at 8:03 PM

Found it!
  • Now I tried rev 6428 (5f0ce05438375dc7f1c1396adf1d2a14f81ebda8) but since it doesn't compile, gone with 6429 (5f0ce05438375dc7f1c1396adf1d2a14f81ebda8) instead and it WORKS.
  • Rev 6431 (527babcd0e6217afb063a38c978cd4a16698bbcd) DOESN'T WORK!
This means the problem lies with the VS 2012 upgrade!

Also tried the same solution (of rev 6431) with VS 2010 (till now I opened every solution with the appropriate VS, i.e. ones pre-dating the VS 2012 migration in VS 2010). This WORKS! However it works only with a clean instance. That means:
  • 6431 doesn't work if built from VS 2012.
  • 6431 doesn't work if opened and run from VS 2010 after having built in VS 2012.
  • 6431 works if built from VS 2010 initially.
    Haven't tried, but I guess completely cleaning the instance after having built with VS 2012 should restore the state where building with VS 2010 makes dynamic compilation working.

nightwolf226 wrote Oct 28, 2012 at 8:30 PM

My result: Dynamic Compilation breaks with Rev #6438 (5d98c880f6c5b9b789b5eb3f3dfe127ab0962a6c).
It doesn't matter which Visual Studio you open the solution in or which devserver (ASP.NET Dev Server or IIS Express) you use.

Although the inconsistent result is a huge bump on the road to fix it...

nightwolf226 wrote Oct 28, 2012 at 10:21 PM

When testing, it's not enough to update to an other revision and purge the repo, as Zoltán mentioned a clean repo is needed to be cloned for testing. With this (more accurate) method I found that the breaking changes are within changeset #3436 (4a2ea78d9b31e96ef181dea5af7a9f3f8e729814), which is still not consistent with Zoltán's results. :(

nightwolf226 wrote Oct 28, 2012 at 10:23 PM

*6436 is the changeset number

sebastienros wrote Oct 29, 2012 at 6:41 PM

@Benedek: 6436 has kind of been deprecated by very recent changes. Can you try with the new release then ?

nightwolf226 wrote Oct 29, 2012 at 10:08 PM

Still not working for me in 1.6.

sebastienros wrote Oct 30, 2012 at 1:20 AM

Trying another explanation. Delete the /bin in the Widgets module, do the modification and see what happens. If it works then, the change you are pointing might be the culprit as it's defining the priority to 50 for the DynamicExtensionLoader, which might have changed how the existing binaries win over local changes if it previously used the PrecompiledExtensionLoader.

nightwolf226 wrote Oct 30, 2012 at 8:36 AM

Testing with 1.6: deleting the /bin folder of Widgets makes it work!
I checked the Priority values of the different loaders and yes, it's about the DynamicExtensionLoader having a lower priority (50) than the PrecompiledExtensionLoader (80). If I set it to 90 (and rebuild, it's necessary), Dynamic Compilation works.

_oliver_ wrote Jul 25, 2013 at 2:15 PM

I'm lost here - I've read the original forum discussion and this thread a few times now and cannot find a fix.

I've tried setting the Priority of the ExtensionProbeEntry returned by DynamicExtensionLoader's Probe method to 90 which resulted in all entries in the dependencies.xml file to use the DynamicExtensionLoader which in turn led to an exception stating that the Orchard.Themes assembly could not be loaded.

I've also tried deleting the \bin folder from the Orchard.Widgets module but that led to a different problem, namely the following log entries:
ExtensionLoaderCoordinator - No loader found for extension "Teamaton.Search"!
ExtensionLoaderCoordinator - No loader found for extension "Discoverize.GoogleMap"!
ExtensionLoaderCoordinator - No loader found for extension "Discoverize.Management"!
That in turn lead to a NullReferenceException in the PrecompiledExtensionLoader line 176:
bool result = references.All(r => r.Loader.GetType() != typeof(DynamicExtensionLoader));
All in all, dynamic compilation still does not work for me in 1.6.1.

What do I have to do to get this fixed before updating to 1.7?

sfmskywalker wrote Mar 28, 2014 at 1:28 AM

Fixed in changeset 7ea13186cdef75f887c572e7d560fcec9df2692d