Evoq Basic 9.3+ Compatibility?

[ABatwildlifecalifornia]

There doesn't seem to be any version of the Events module that is compatible with Evoq Basic 9.3, and the installation package doesn't include such a module. Are there plans to work toward compatibility?

I'm not clear on the development fidelity between the Community and Evoq products, but a DNN Corp support tech (Abdulla Eldemerdash) confirmed that the Events module isn't compatible with Evoq Basic 9.3.2, and said I needed to contact someone here on the Community GitHub page. I see from https://github.com/DNNCommunity/DNN.Events/issues/79#issuecomment-391634576 that @EPTamminga didn't have an Evoq license for testing in 2018. Is that still the case? I'm happy to help with testing.

Steps to reproduce the behavior:

1. Install new instance of Evoq Basic 9.3.2 (does not include Events module or anything similar)
2. Install any 6.x or 7.x version of Events module (6.3.1 is currently installed because that's the latest version that will work with Evoq Basic 9.2.2).
3. Updated instance with Debug DLL's provided in https://github.com/DNNCommunity/DNN.Events/files/2034434/Events700_Debug_DLLs-3.zip.
4. Result: error is displayed on page where Events instance is placed (see below).

Thanks for any help you can offer!

Error: Events is currently unavailable. DotNetNuke.Services.Exceptions.ModuleLoadException: Could not load file or assembly 'DotNetNuke.Web.Deprecated' or one of its dependencies. The system cannot find the file specified. ---> System.Web.HttpParseException: Could not load file or assembly 'DotNetNuke.Web.Deprecated' or one of its dependencies. The system cannot find the file specified. ---> System.Web.HttpParseException: Could not load file or assembly 'DotNetNuke.Web.Deprecated' or one of its dependencies. The system cannot find the file specified. ---> System.IO.FileNotFoundException: Could not load file or assembly 'DotNetNuke.Web.Deprecated' or one of its dependencies. The system cannot find the file specified. at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString) at System.Web.Configuration.CompilationSection.LoadAssembly(String assemblyName, Boolean throwOnFail) at System.Web.UI.TemplateParser.AddAssemblyDependency(String assemblyName, Boolean addDependentAssemblies) at System.Web.UI.MainTagNameToTypeMapper.ProcessTagNamespaceRegistrationCore(TagNamespaceRegisterEntry nsRegisterEntry) at System.Web.UI.BaseTemplateParser.ProcessDirective(String directiveName, IDictionary directive) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at DotNetNuke.Modules.Events.Events.LoadModuleControl() --- End of inner exception stack trace ---

[jncraig]

Which version of the Events module produces this error?

The release notes say "DNN.Events 07.00.04 will work for any DNN version 8.0.1 and up to the latest release of DNNPlatform. Full details on the changes can be found in great detail at the repository on GitHub." and that was as of June 17.

DNN 9.3.2 was released on May 1, so ... the latest release of Events should (per the notes) work.

If it doesn't, I'm sure that EPT will have that sorted our quickly.

---

By the way, it has been several years since DNN Corp quit shipping extra modules with both the Platform and Evoq releases. Fortunately, the DNN Community has revived most of the old "core" modules and is maintaining them here on GitHub for the benefit of all of us. The module maintainers deserve all the praise we can give them!

[jncraig]

Kudos to you for doing your testing on a clean install of Evoq!

You should also know that DNN 9.3.x is where a number of cleanups (which knowingly created a number of breaking changes) were introduced. Many modules had to be fixed and recompiled to be compatible with the later versions. And, the nomenclature for DNN PLatform and Evoq are in agreement, so 9.x.y is the same for both.

It looks like you copied 7.0.0 dlls into your existing installation. It's not surprising that generated errors.

Have you tried upgrading Events to the latest module release?

[ABatwildlifecalifornia]

Before specifically updating the DLLs today, I tried every 6.x and 7.x version of the Events module, with the same result. Just now I updated the module to version 7.0.4 and restarted application, with no change.

[jncraig]

Just for fun, I went to a clean install of DNN 9.3.2 and installed Events 7.0.4.

I added the Events module to a page and configured an event. I can view and edit the event.

Now, this was DNN 9.3.2 and not Evoq 9.3.2, but Evoq is built on the DNN Platform.

Can you try completely removing the Event Module (on the Extensions Persona Bar tab, and then reinstalling Event 7.0.4. Hopefully that will work. If not try again by deleting the 9.3.2 install and redoing it.

I hope that helps.

[EPTamminga]

@ABatwildlifecalifornia I think Evoq is missing the Telerik DLL & the deprecated DLL.

Have a look here: https://github.com/DNNCommunity/DNN.Faq/issues/33 for a similar problem and solution

[ABatwildlifecalifornia]

That did the trick! I understand you're all volunteers, and really appreciate your shared time and expertise. Thank you!

[jncraig]

Excellent!

[JaySMa]

@ABatwildlifecalifornia I think Evoq is missing the Telerik DLL & the deprecated DLL.

Have a look here: DNNCommunity/DNN.Faq#33 for a similar problem and solution

Can the events module be update to remove this dependancy?

Off topic, but we too run Evoq and since the company took over Evoq, my bosses have been displeased with the responses we get for paid "support"; it's bad. Seems like they're more about getting the money than giving support. Such-as Ernst getting a simple time-limited Evoq development license to test community modules between the different DNN / Evoq installations. This should be a given. And the lack of free modules with a clean installation; core modules should be included and supported by DNN. It's gotten to the point that after running DNN/Evoq for over 10 years, we're researching other CMS systems as replacements.

[ABatwildlifecalifornia]

@JaySMa : I agree. The only thing we need from Evoq is the approval workflow feature. Otherwise I'd be more than happy to move to the community Platform (though the process looks daunting). The community volunteers seem to have much more knowledge and willingness to help than the paid DNN Corp support folks. On the other hand, going without paid support is a scary prospect because I manage our DNN sites, and don't have a programming background.

We just spent $25K in public funds to extend licensing through early '22, and I'm not pleased.

[EPTamminga]

@JaySMa Migrating from Evoq to Platform is not very difficult, but takes some work and testing.

[EPTamminga]

@JaySMa removing telerik in Events is not a simple 123. The Telerik UI components are used in several places in the module and there is not a simple replace with something else.

[jncraig]

Not sure what you mean by "when the company took over Evoq." DNN Corp has always owned DNN Professional which was renamed Evoq several years ago.

What has changed is the DNN Corp gave the IP rights for DNN to the .NET Foundation and the DNN Platform (Community Edition) is now guided by a community organization. Check the blog at dnnsoftware.org and you'll find some detailed descriptions of how the whole thing works. And DNN Corp is also involved with the development of DNN Platform.

The decision to remove the "core" modules from DNN and Evoq distributions was made several years ago. At least part of the intention was to slim down DNN. That work continues, and will likely accelerate in the future. But, the old "core" modules continue to be supported, too.

On Fri, Dec 27, 2019 at 2:16 PM JaySMa notifications@github.com wrote:

@ABatwildlifecalifornia https://github.com/ABatwildlifecalifornia I think Evoq is missing the Telerik DLL & the deprecated DLL.

Have a look here: DNNCommunity/DNN.Faq#33 https://github.com/DNNCommunity/DNN.Faq/issues/33 for a similar problem and solution

Can the events module be update to remove this dependancy?

Off topic, but we too run Evoq and since the company took over Evoq, my bosses have been displeased with the responses we get for paid "support"; it's bad. Seems like they're more about getting the money than giving support. Such-as Ernst getting a simple time-limited Evoq development license to test community modules between the different DNN / Evoq installations. This should be a given. And the lack of free modules with a clean installation; core modules should be included and supported by DNN. It's gotten to the point that after running DNN/Evoq for over 10 years, we're researching other CMS systems as replacements.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/DNNCommunity/DNN.Events/issues/206?email_source=notifications&email_token=ABEDMRMB5EEZRYZEWD6YXQTQ2ZIA5A5CNFSM4J7PW2R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHXUM2Q#issuecomment-569329258, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEDMRPAA6FYHYBJZ6QV5WLQ2ZIA5ANCNFSM4J7PW2RQ .

[valadas]

Can the events module be update to remove this dependancy?

It sure can, but it is a quite big undertaking and this is true for many other core modules. It is the next big thing to do for all of the core modules since it will also be removed in Platform, and then we will also have another big item which is migrating them all out of webforms. Two massive undertakings that will be handled by a handful of volunteers, so it may take some time. But yeah, those are in the plans.

On the other hand, going without paid support is a scary prospect because I manage our DNN sites, and don't have a programming background. We just spent $25K in public funds to extend licensing through early '22, and I'm not pleased.

Well a lot of people use Platform and hire developers as needed for support/development. That being said if you need Evoq specific features, that might be another story.

You should also know that DNN 9.3.x is where a number of cleanups (which knowingly created a number of breaking changes)

Actually 9.2.0 was the huge breaking changes version for third party modules, In 9.3.x we started working more on the Persona Bar stuff.

Also Evoq versions do not (unfortunately) always map to the same Platform versions, see https://www.dnnsoftware.com/docs/developers/product-versions.html which makes it difficult when people using Evoq ask questions to the community.

[thabaum]

@valadas

migrating them all out of webforms. Two massive undertakings that will be handled by a handful of volunteers

I am all for helping out here as I would like to learn all I can about how things are going to work in Dnn.Next and I can program I just don't want to waste too much resource on things that need to get re-written.

I am still trying to dig into the differences to help push this along as I know dire need of any kind of help. So as far as the Events module goes. What "Needs" to be done specifically.

If I am understanding things correctly we need all modules to move from web forms to razor pages? Please let me know exactly what I need to study over the coarse of the next few months I will hone my skill set around those technologies.

**Does this need to be done on MVC or SPA template?

Last what would be the best approach for you to start a project like this?**

The answer to these questions would really help someone that is looking to help and might be able to "volunteer" their help. Since these tasks need to get done anything we are aware of for a solution that should be getting done now for module developers maybe we can make a sticky note in the forum and dnn docs areas that can help build awareness for the need to make this happen asap for the community.
I have been wrapping my head around things like never before for the cause and donating all my time and solutions along the way. It has been a fun challenge. I thank everyone for helping me along the way in my journey here as it has helped out a lot just so I can help out a little. Hope everyone has a happy new year!

[thabaum]

This article on Razor Pages replacing webforms from telerik gives a pretty good idea of what is needed to evolve DNN. This answered my questions thanks.

[valadas]

Yes, Razor pages is one option that kinda get's a bit close in architecture, but ultimately it will depend on each maintainer preference, I for one am a big fan of pure html/css with WebAPIs.

[thabaum]

Is there any related articles moving from web forms to pure html css and webapi's

I am just trying to weigh options and amount of work for each. If we made DNN Events future proof what is going to be the future stack is my question we need answered here. Maybe a great blog post on the dnn community site to explain this I bet would hit some big talking points similar to the one posted in the Telerik forum. I don't really have a dog in this fight so I just want to know what skills are needed to allow DNN Events and other DNN modules to survive. If we can fix the current modules first that would be nice if they are able to co-exist with old and new version of DNN .NET Core version. Or is that the cart too far in front of the horse for that option now?

I have read a lot recently and will continue my research as it is a personal goal of mine and I am highly motivated I just need to know how I can spend my time most wisely.

DNN Events was recently written for C# so now it is about planning the next big step towards .NET Core environments. Upgrading one of these modules from .NET Web Forms to any other acceptable solution is very tasty subject matter for anyone looking to blog on the topic at hand here.

A well thought out tutorial video with steps of how a module was updated to be future proof and acceptable would be worth a ton in gold for the community of interested and upcoming developers. We could use some fresh material possibly for version 10 to go for the updates to version 11.

Sounds to me like vNext might be alpha for a while until it can catch up to the latest version of .NET Core.

I am all for simplicity. If DNN Events can run just on HTML, CSS and WebAPIs or Razor Pages we should weigh in on those options @EPTamminga for version 8?

Thank you.

[EPTamminga]

@thabaum Good morning. I am following an interesting discussion here.

As for moving a core module to the future (.NET Core), my suggestion is not to start with Events.

Of course, you are free to do so, but... i.m.o. Events is a complex and large core module, including a custom control (the month/week calendar) and interactions with groups, social, activity.

Using a simpler, smaller core module in order to learn how to do a transition would be better way both for learning as well as creating sample material on how to do things, e.g. DNN.Links,. DNN.IFrame, DNN.XML, DNN.Reports.

[thabaum]

@EPTamminga I agree for learning and teaching if someone like @valadas wished to produce a how to tutorial to help someone like me or any maintainer for any of the modules. Some of the modules for DNN are becoming stale such as DNN Forums and Active Forums. No one knows really which should be developed on or what to do next if they did do something it feels like.

A lot of disarray here and it is no one's fault as I am not trying to point fingers it is just a community thing we need to work out IMO.

So to support the development of these it feels we need active maintainers of the modules that are meant to survive and downsize things making migration paths to what will be supported possibly. A lot of work... but talking about things only goes so far.

[thabaum]

So my remaining question is Razors Pages or HTML CSS and WebAPI?

Please choose for me I will learn to do it that way for one of those DNN modules cores listed first.

[EPTamminga]

@thabaum For me: HTML/CSS and WebAPI.

This will create a clean separation between UI, business logic and data storage. It opens up options for connecting mobile apps and it forms a basis for a headless CMS.

[valadas]

Is there any related articles moving from web forms to pure html css and webapi's

Unfortunately, it is not a simple migration. Webforms was a technology build from the ground up to make it similar to windows application development, with state and events. It was to be easy on both current Windows developers and to try and attract php developers that do everything on a page context at that time. It did not scale very well and kinda contradicts the stateless nature of http protocol. Webforms kinda made it easy to have all the code in the view (not always the case depending on the developer and module). Modules that have proper isolation of concerns will usually have a business logic layer that make them a bit more easy to rewrite just the view part, but it is not always the case and for some modules only the data part needs to be kept and all the rest needs to be rewritten. Again I am talking in general and that varies from module to module.

Razor pages will be a little bit similar to webforms and it would be probably the easiest migration path for some of these modules that have all the logic in their view. But I do love the cleseness to web standards of WebAPI paired with pure html/css (Sometimes called SPA module). I think this is what has the best survivability for anything that will happen in the next 10 years :) It also makes a very strong separation from UI and backend which makes it easy for front-end developers to work on the UI and backend developers to work on other stuff.

This module is certainly not one to build a simple example of migration :) It is a rather complex one. In 2020 I will certainly make a video rewriting one of the simpler ones like FAQ or something very basic just as an example.

[EPTamminga]

@valadas Well said.

[thabaum]

@valadas great this brings some clarity to the party here. It would be great to see an example video with this type of migration.

I say do what will survive... sounds like they are both very similar approaches and what you describe is referred to as SPA? Razor Pages would be the MVC approach then?

I think I am understanding this better now. I have always been a fan of SPA modules myself as well so that is refreshing as I wasn't sure this was the direction things are heading. I wanted to get into SPA modules for DNN but was afraid it was just going to be lost time... now I am excited even more :) as I am feeling things out correctly, and now I have verification that I am in good company.

I want to learn them both very fluently over the next year the best I can. I had a lot come up over the last month that was very unexpected. I will be doing some catching up homework here soon and this was eating at me for some things I can do to help get things ready for .NET Core version.

I want to push to .NET Core as fast as possible so anything I can learn to help I will.

Thank you.

[thabaum]

@EPTamminga This sounds like the way to go then as I was hoping to go with the flow of what will work long term and easiest to maintain for any maintainer if I was to submit a solution.

For something like a complete re-write I will probably get things working and once I learn that I will be able to add these features I desire to these modules down the road. I just want to be on the same page as you and others the best I can.

Thank you and happy new year !

[valadas]

Razor Pages would be the MVC approach then

Nope, actually you can use Razor in MVC modules, but Razor pages is a bit different.

Razor Pages is scoped per page and has a direct mapping between the page (razor script) and the model is a representation for the whole page, this is why is is more archetecturally more similar to Webforms and has a method for when the page initially loads and a method for when the page posts-back.

MVC is Model-View-Controller, it is largelly basec on a convention that each thing will have a file with the same name in a model folder, a view folder and a controller folder. Those things are not pages per se, but parts kinda. And they could have partial parts inside others, etc.

SPA stands for Single Page Application and is kind of a bad naming if you ask me in the Dnn context of a module because it has nothing to do with pages actually. Internally this is refered as the html5 module pipeline in Dnn, I don't know who came of first calling this pipeline SPA. In the context of Dnn, this pipeline has basically just WebAPI endpoints on the server side and plain html/css/javascript for it's front-end. This means the frontend is totally independent from Dnn and as long as something provides those server endpoints it will work. For me this is the most standard way to build stuff and well there are very few breaking changes in W3C standards as html/css/javascript. It is for me my preference but that is only my opinion.