Does anybody have successfully working module in DNN 6 with the Ajax Control Toolkit?
My modules stopped working when we migrated from DNN 5.x to to 6.x.
Modules compile without errors but I am getting client side script error:
'AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the ToolkitScriptManager in AjaxControlToolkit.dll'
Seems like this is conflict with Telerik's controls, according to information that I have found. But I didn't find any info how to fix it.
You should be able to use older versions of the ASP.NET AJAX Control Toolkit, but once they start requiring the ToolkitScriptManager, you're out of luck with DNN (though you'll be out of luck with any version of DNN, since there's not a way to override the type of ScriptManager it uses.
Starting with DNN 6, they use Telerik's RadScriptManager. Previously, you could modify the core code to switch out for the ToolkitScriptManager, but now switching out might cause other issues.
It could work together, but you'll need do some modifications to the core of DNN.
Here the list of things to do:
Check that you're using latest version of .Net 4.0 binaries of AjaxControlToolkit (I was able to let it work for DNN 6.0.1 with Telerik 2011.01.519 and ACT September 2011 v4.1.50927)
Check that in your web.config you have assembly binding redirects for System.Web.Extensions and System.Web.Extensions.Design to the version 4.0
Take DNN source package, find Library\Framework\AJAX.cs, locate method AddScriptManager, instantiation of RadScriptManager in it, for the version 6.0.1 look into line 54. Add one more property initializer:
EnableScriptCombine = false. Compile it (in Release configuration, of course), take DotNetNuke.dll and drop into your DNN installation.
You should be done.
Credits goes to Telerik support, despite it's stated there that it should work out of the box starting from 2010.1.625. Not sure, did I get them wrong, or they just reintroduced this bug.
P.S. DNN support promises to release version 6.1.0 in November with updated Telerik controls, which should fix this issue, at least on their opinion.
Just checked with nuke 6.1 and the last version of jaxcontroltoolkit - still the same error.
It looks like it's not supported anymore. Sad:(
Related
My agency is developing using the CE version in anticipation of purchasing a license. We are creating xforms by hand using the 2019 CE version, using jsp's in a Java tomcat application (separate deployment). I downloaded the 2020 version (hoping to use the 5.x version of TinyMCE) and found that rich text controls no longer appear using the same xforms used with the 2019 version. Looking at the browser page inspector (Ms edge), it appears that the TinyMCE resources (js and css) aren't downloaded to the browser at all. No html elements are created for the editor. I didn't see a console error or see an http error for the resources.
I couldn't find any issues related to TinyMCE in this version. Has anyone else seen this? Is there a configuration difference between the versions that may be causing it? (I reused the configuration I had from 2019 version). Anyone have suggestions on what to look at?
When I reverted to the 2019 version it works again. Any help would be appreciated!
I am not aware of any issue with the TinyMCE and Orbeon Forms CE 2020.1.2. I would recommend you try to reproduce this with an out-of-the-box install, and if it works there, progressively put back your existing configuration on that out-of-the-box install.
If you are doing this with the perspective of using Orbeon Forms PE, I would just use the latest release of Orbeon Forms PE 2020.1.3 with a trial license, as this way you'll have a configuration that is as close as possible to what you're ultimately planning to have, and you will benefit from having all the latest released fixes.
(And should this not solve the problem, feel free to post more information in the comments.)
I am using Autofac in a project that is being obfuscated using Dotfuscator. the dotfuscator fails saying it cannot find mscorlib version 2.0.5.0
Is there a way to tell Dotfuscator how to obfuscate Autofac with portable Dll?
Is Autofac team planning releasing autofac with reference to .NET 4.0?
Any other suggestions?
I don't know what version of Dotfuscator you're using, but it does seem that at least as of 4.9.9000 they "know" about Portable Class Libraries. If you aren't at that version and can't upgrade, you might need to contact Dotfuscator support to find out a solution. (Another question of similar nature also pointed to updating Dotfuscator as the answer.)
A similar sort of issue occurs with FxCop analysis and SecAnnotate. To get around those issues with those tools, you need to tell them to ignore version information on certain assemblies (like System.Core and mscorlib). You may need to use an option like that on Dotfuscator if such a thing exists.
PCL can also cause challenges on machines that don't have all the latest .NET patches. Make sure you're patched up.
There is no plan to release an Autofac tailored just to .NET 4.x Autofac is a Portable Class Library so it can support multiple platforms without conditional compilation, making for easier testing and development. It switched away from platform-specific builds as of 3.0 and there's no plan to go back.
If upgrading Dotfuscator and patching your machine doesn't fix the issue, your best bet is to find the Dotfuscator mechanism for ignoring assembly version.
I wanted to follow up on a post from last year ("EF5 , Widows Forms , Dragging a chield entity from project datasource into a GridView creates only 2 columns").
I believe the problem described with EF5 is still true and the solution found (use EF4) continues to be the only reasonable answer.
Before I upgrade to VS2012, I wanted to check whether anyone knows if there is any problem using EF4 in VS 2012.
Anyone with experience on this?
VS2012 requires .NET Framework 4.5 which is an in-place update. This means that once you install the .NET Framework 4.5 it will be always used when running .NET Framework 4 or .NET Framework 4.5 apps. This also means that you will be running EF5 even if you target .NET Framework 4 in VS (targeting is only a design time thing which prevents from using APIs that were not available in the targeted .NET Framework version while at runtime the app will use the version installed on the box).
With regards to the problem you are reporting - take a look at this bug report on the EF codeplex site as it apparently contains a solution to the problem
We are using enterprise library 4.1 and smart client software factory 2008 to our application.
how we can upgrade enterprise library 5.0 and SCSF 2010 to our application.presently we are using visual studio 2008.
To upgrade what are the thing needs to be taken care.
Early help would be appreciated.
In terms of Enterprise Library, the best case scenario would be to replace the 4.1 assembly references with 5.0 assembly references and change the configuration (to use 5.0 references instead of 4.1 references). However, you could also hit some issues.
You should read the Microsoft Enterprise Library 5.0 Migration Guide for a full description. The Breaking Changes document could also help you determine if you may run in to migration issues.
For the Smart Client Software Factory the approach appears the same: change the references and configuration to use the new dlls. The Web Client Software Factory 2010 Documentation download has a section on Migrating to Visual Studio 2010.
Install the 5.0 package.
remove all the previous refreneces and add the newer ones generated.
You can refer the dlls by copying it to some folders or directly from the location where you have installed (C:\programfiles\Microsoftenterpriselibrary5.0)
I faced the below issues while migrating
Configuration errors in web.config files - some of my references in the web.config files were refering to the older version(2.0.0.0)(i upgraded from 2.0 to 5.0) and the publictokenkey="null"
so i pushed all the dlls to the gac and added the publicktokenkey from the c:\windows\assembly. which solved the issue
And another issue was regarding the microsoft.practices.enterpriselibrary.caching.cryptography- it was displaying soem weird error.- solution-the bin folder was having the old dlls and when tried to
clean the solution the dll reference was still there. SO i deleted all those from the folder and rebuild again.
IT was initially having the logicacmg.enterpriselibraryextensions.logging which caused some issues- i used the microsoft.practices.enterpriselibrary.logging.configuration.rollingflatfiletracelistenerdata which could solve the issue.
Hope some one might get some inputs with this post
I recently started to use AjaxControlToolkit v3.0.30930.0 in my application together with System.Web.Extension 3.5.
My development environment is Visual Studio 2005, .NET Framework 2.0 and the development language is C#.
The Ajax control I used is the ModalPopupExtender. I also used the UpdatePanel and updateprogress controls.
Everything is working fine on my development machine. But I got a problem after I deployed the application to a server which does not have System.Web.Extension 3.5 installed, which is understandable.
My question is, can the ajax controls I used work without System.Web.Extension 3.5? Say I revert the ajaxcontroltoolkit back to version 1.0.61025.0? I don't have the option to install .NET 3.5 as yet.
Thank you for your help.
John
I figured out a solution to my question.
Here is what I did.
I set my project to reference version 1.0.61025.0 of system.web.extension dll and version 1.0.20229.20821 of ajaxcontroltoolkit. Then I updated all the relevant settings to tell .NET runtime to load version 1.0.61025.0 of system.web.extension dll. It worked out fine.
Hope this is of some help to somebody.
John