Hi Guys,
we are having some problem after upgrading to 16.1.7. As you know XPObjectType table contains old assembly names, and so it seems there is a Problem when an Client has both DevExpress.ExpressApp.v16.1.dll and DevExpress.ExpressApp.v14.1.dll in its directory. Our updater currently deletes all old devex assemblies, but when this fails (because for example of restricted rights) - the client cannot open any detailviews anymore. we can solve this by either delete all devex 14.1 dll's - or by upgrading the xpobjecttype table manually. can you please look at this situation, either change the method how you create the detailpropertyeditor? - or provide an out of the box updater for the xpobjecttype table? (see other ticket).
Type: ObjectCreatingException
Message: Unable to create an instance of the "DevExpress.ExpressApp.Editors.DetailPropertyEditor" type.
Reason: "Der Konstruktor für den Typ "DevExpress.ExpressApp.Editors.DetailPropertyEditor" wurde nicht gefunden."
.ctor(System.RuntimeType, ModelPropertyEditor) is absent.,
stack trace: " bei System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
bei System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
bei System.Activator.CreateInstance(Type type, Object[] args)
bei DevExpress.ExpressApp.Utils.Reflection.TypeData.CreateInstance(Object[] args)"
end stack trace
Data: 0 entries
Stack trace:
bei DevExpress.ExpressApp.Utils.Reflection.TypeData.CreateInstance(Object[] args)
bei DevExpress.ExpressApp.Editors.EditorsFactory.CreateViewItem(Type viewItemType, String viewItemId, Boolean checkConstructor, Type objectType, IModelNode modelViewItem)
…
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
----------------
InnerException:
Type: MissingMethodException
Message: Der Konstruktor für den Typ "DevExpress.ExpressApp.Editors.DetailPropertyEditor" wurde nicht gefunden.
Data: 0 entries
Stack trace:
bei System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
bei System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
bei System.Activator.CreateInstance(Type type, Object[] args)
bei DevExpress.ExpressApp.Utils.Reflection.TypeData.CreateInstance(Object[] args)
InnerException is null
Hello Noxe,
We need some additional time to replicate this situation and think of the best technical solutions. For now, your current solutions look correct.
Having the same Problem right now localy on my machine - seems because i have installed 14.1 and 16.1 side by side. after manually updating the database error is gone:
update XPObjectType set AssemblyName = REPLACE(AssemblyName,'v14.1','v16.1')
Hi Noxe,
We are currently creating a spike solution to avoid using direct SQL for this task. I will contact you if we succeed in a reasonable time and have something for you to test with the latest build.
In short, this db-server agnostic updater does not look complex. See the attached XPO sample.
There is also another solution (SQL Server-specific) to update the XPObjectType table - using the protected UpdateXPObjectType method of the ModuleUpdater class.
The main difficulty or risk for us is that modifying the XPObjectType table by removing old references from it is a very serious change that may affect other apps using this database. Such updates must be done on demand only when required and there are already options for our users to do this using the APIs above.
Thx Dennis - yes - in fact it should update ALL DevExpress assemblies to the current Version. attached is a Screen of a typical datanbase. so you can replicate the ObjectCreatingException?
Hi Noxe,
I would appreciate additional information (a sample along with the exact repro steps, ideally) on replicating this error, because I am having difficulties replicating it using our MainDemo.Win when the XPObjectType table and the application directory look as in the attached screenshot. I have marked this ticket as private so that you could attach your test app here, if required.
Hi Dennis,
i can replicate it in MainDemo with these modifications. as far as i see the problem is loading the moduleinfo table - here it happens that those old assemblies are loaded (i handled AppDomain.CurrentDomain.AssemblyLoaded Event to verify).
28 DevExpress.ExpressApp.Workflow.Versioning.XpoUserActivityVersion DevExpress.ExpressApp.Workflow.v14.1
29 DevExpress.ExpressApp.Workflow.Xpo.XpoWorkflowInstanceControlCommandRequest DevExpress.ExpressApp.Workflow.v14.1
30 DevExpress.ExpressApp.Workflow.Xpo.XpoRunningWorkflowInstanceInfo DevExpress.ExpressApp.Workflow.v14.1
31 DevExpress.ExpressApp.Workflow.Xpo.XpoStartWorkflowRequest DevExpress.ExpressApp.Workflow.v14.1
32 DevExpress.ExpressApp.Workflow.Xpo.XpoWorkflowDefinition DevExpress.ExpressApp.Workflow.v14.1
using (var dataLayer = DevExpress.Xpo.XpoDefault.GetDataLayer(winApplication.ConnectionString, DevExpress.Xpo.DB.AutoCreateOption.None))
{
dataLayer.Dictionary.CollectClassInfos(typeof(ModuleInfo));
using (var session = new Session(dataLayer))
{
foreach (var module in new XPCollection<ModuleInfo>(session))
{
}
}
}
winApplication.Setup();.
Hi Noxe,
Your 4th step was the key - I can now stably replicate this behavior locally even with my existing XPObjectType records. Thanks a lot!
Perfect! :)
While we are at it, would you please also remind me why this code is required in your app?
using(var dataLayer = DevExpress.Xpo.XpoDefault.GetDataLayer(winApplication.ConnectionString, DevExpress.Xpo.DB.AutoCreateOption.None)) { dataLayer.Dictionary.CollectClassInfos(typeof(DevExpress.ExpressApp.Xpo.Updating.ModuleInfo)); using(var session = new Session(dataLayer)) { foreach(var module in new XPCollection<DevExpress.ExpressApp.Xpo.Updating.ModuleInfo>(session)) { } } }
Is it a part of your custom versionning mechanism or what?
I am loading Modules from the Database (like loading from config file). I have a custom field "IsCustom" - and then i add to the Application.Modules list
Thanks for your clarification, Noxe.
hi dennis - do you have any update on this?
thx
Hi Noxe,
We have not yet avoided this behavior by default. Do you have any problems with your current solution?
yes and no. works for 95% for our customers - only fails if dll's cannot be deleted for what reason ever. then we have to manually help there.
it is also a Problem localy for developers if you have 14.1 and 16.1 installed on the machine. here, when working with a customers database, you always need to update the xpobjecttype table .
Thanks for your update, Noxe - we will take it into account when prioritizing our work
thx Dennis
fyi - having the same Problem now localy when upgrading to 17.1 and both 16.1 and 17.1 are installed on the machine