November Happy Hour will be moved to Thursday December 5th.

forceBinFolderScan="false" gives 404 to edit mode

Vote:
 

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

e.g.: 

<scanAssembly forceBinFolderScan="false">
<add assembly="*" />
</scanAssembly>

#69764
Apr 05, 2013 9:45
Vote:
 

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.

#69766
Apr 05, 2013 10:32
Vote:
 

Ok, so its a bug then or removed feature?

#69771
Apr 05, 2013 11:54
Vote:
 

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.

#69863
Apr 08, 2013 17:32
Vote:
 

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?

#74391
Aug 27, 2013 11:12
Vote:
 

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.

#75549
Sep 28, 2013 10:14
Vote:
 

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 ;

#75965
Edited, Oct 14, 2013 11:20
Vote:
 

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.

#76180
Oct 18, 2013 14:33
Vote:
 

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.

#77991
Nov 29, 2013 17:38
Vote:
 

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

#78001
Dec 01, 2013 12:30
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.