Setting forceBinFolderScan="false" in episerver.framework.config gives 404 to edit and admin mode. use to work fine in EPiServer CMS 6.
Is this a bug or am I missing something?
I'm Using the mvc version and the url becomes: http://localhost:37003/Home#context=epi.cms.contentdata:///5
<scanAssembly forceBinFolderScan="false"> <add assembly="*" /> </scanAssembly>
forceBinFolderScan="true" is required to load and scan assemblies in modulesbin folder, where add-on assemblies are deployed.
Since in EPiServer 7 Shell UI and Edit UI modules are add-ons, it explains why these modules are not initialized when forceBinFolderScan is set to false.
Ok, so its a bug then or removed feature?
It looks like this feature is partially redundant in EPiServer 7, since all assemblies in bin folder are loaded in any case. You can disable loading add-on assemblies from modulesbin folder by setting forceBinFolderScan="false", but I cannot imagine when you really want it.
So probably this configuration option is going to be obsolete in the next platform version.
I have the same problem in my site.
forceBinFolderScan is set to true, but I want to remove an assembly from the scan. Nothing happens if I add the <remove assembly="gsdll64.dll"/> to <scanAssembly>
The gsdll64 is scanned anyways and the site crashes since gsdll64 isnt a .net assembly, but is needed for ghostscript pdf2png conversion.
If I set the forcebinfolderscan to false and put <remove xxxxxxx> the site works, but the we have no shell/edit ui.
Is there anyway to get this to work?
Same thing here.
Have an assembly that is not a .NET assembly which is since EPi7 impossible to have in \bin
Only option seem to be to move it to c:\Windows\System* folder which is not that popular.
You could try the following workaround: assembly is deployed in other folder that is listed in probing path, so it is not scanned but can be loaded. Please see details here: http://world.episerver.com/modules/forum/pages/thread.aspx?id=52970#53487
Does it solve the problem?
updated: make sure that existing path "modulesbin" remains in the probing path configuration. You can specify several paths separated by ;
Dmytro, can't find any information this will work for non-managed assemblies with P/Invoke.
At least i'm not able to get it to work.
Agree, this probably will not work with unmanaged dlls.
What if you try embedding unmanaged dll in .NET assembly that can load this embedden dll when it's needed? If it works, you can try the workaround above for .NET assembly.
Might work , though in this case it's a third party plugin doing the P/Invoke so can't do anything there.
According to EPiServer support there are some bugs related to scanning unmanaged assemblies which will be resolved in v7.5