Remove PageData instance works only once

Vote:
 

I get the above error the _second_ time I run

_contentRepository.Service.Delete(startPage.ContentLink, true, EPiServer.Security.AccessLevel.NoAccess);

If I IIS-reset it works _one_ time, then I get the above error again. Same thing applies to 

_contentRepository.Service.Save(...);

Any ideas what I'm doing wrong?

#201440
Edited, Feb 19, 2019 12:58
Vote:
 

I found the cause of my problem and also found a (not so nice) workaround. Maybe you guys know a better way of fixing this?

  • I had a nuget GUI plugin module that needed some Initialization-code to be run.
  • The Initialization code was located in the same VS-projekt (and assembly) as my plugin.

This is how it looks:

namespace Diamir.Epi.Migrations.Initialization
{
    [InitializableModule]
    [ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
    public class MigrationInitialization : IConfigurableModule
    {
        /// <summary>
        /// Adds all types that implements interface IMigration to the IOC container
        /// </summary>
        /// <param name="context"></param>
        public void ConfigureContainer(ServiceConfigurationContext context)
        {
            context.StructureMap().Configure(c =>
            {
                c.AddRegistry((MigrationRegistry)Activator.CreateInstance(typeof(MigrationRegistry)));
            });
        }

        public void Initialize(InitializationEngine context) { }

        public void Uninitialize(InitializationEngine context) { }
    }
}

namespace Diamir.Epi.Migrations
{
    public class MigrationRegistry : Registry
    {
        public MigrationRegistry()
        {
            Scan(s =>
            {
                s.TheCallingAssembly(); // tested also s.AssembliesFromApplicationBaseDirectory();
                s.AddAllTypesOf<IMigration>();
                s.SingleImplementationsOfInterface().OnAddedPluginTypes(t => t.Singleton());
            });
        }
    }
}
  • I installed the nuget plugin into my CMS site
  • I added some classes that implemented IMigration, then I started to se the strange error message above.
  • "Solution" that I found was to put the Initialization code in the folder "modules/_protected/*moduleName*/Initialization/InitializationCode.cs", and put it to "content" instead of "compile" thus making the initialization code part of the consumer assembly rather than the nuget module assembly. If I do like this, I don't get the errors.

I'm not sure why moving the initialization code to another assembly solves the problem and I know this fix is rather bad for a number of different reason. Can't even be sure that the InitializationCode.cs can compile in the consumers project. Anyone have any other suggesttions?

How do you usually handle Initialization code in plugins, where the idea is that the consumer project should be able to add classes that implements an interface provided by your plugin and these classes should be put in the IOC sandbox?

#201450
Edited, Feb 20, 2019 6:58
Vote:
 

I found a better workaround!

Basic problem was that when I used s.AssembliesFromApplicationBaseDirectory(); in StructureMap Scan it scanned all assemblies (including all EPiServer-assemblies) and tried to find implementations of my IMigration interface and add them to the IOC. This for some reason generated the error above.

If I excluded all EPiServer assemblies in the Scan by use this code when scanning the assemblies, it works fine. I can now keep the init module and IOC registration in my nuget plugin.

    public class MigrationRegistry : Registry
    {
        public MigrationRegistry()
        {
            // Need to exclude EPiServer assemblies since we get non-thread-safe-exceptions if we include them in scan.
            var nonEpiAssemblies = AppDomain.CurrentDomain.GetAssemblies()
                .Where(x => !x.FullName.ToLowerInvariant().Contains("episerver"));
            foreach (var assembly in nonEpiAssemblies)
            {
                Scan(s =>
                {
                    s.Assembly(assembly);
                    s.AddAllTypesOf<IMigration>();
                    s.SingleImplementationsOfInterface().OnAddedPluginTypes(t => t.Singleton());
                });
            }
        }
    }

Maybe there is a better solution, but this is far better than the previous workaround.

#201954
Edited, Mar 08, 2019 10:25
Vote:
 

for my libraries I actually tend to provide lambda for the hosting environment to provide filter expression for me to execute before concluding on scanable list of assemblies. sometimes it's not worth to wait for the scanner to do job on Microsoft.* or System.* assemblies if I know that it's not worth that and library will not find anything interesting there..

#202007
Mar 11, 2019 21:19
Vote:
 

Alright, sounds like a good idéa to have a bit more sophisticated approach to the filtering. Maybe using regexp on the assembly names would be a good to get even more control of what assemblies should be filtered out.

#202015
Mar 12, 2019 6:53
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* 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.