When copying a Derived Element the attributes (e.g System.ComponentModel.DataAnnotations.DisplayAttribute) of the Derived Element fields are not copied, not are custom properties.

• Right click on a Derived Element - copy
• Right click on the Containing Model Node - Paste fullThe Derived Element attributes are there in the copy but not its fields V5.4.4 16-Oct-2018

Hi Tom,

I reproduced the behavior. When copy/paste derived elements, the custom attributes (code gen info sub tab) are not copied. We will look into this...

This behavior is by design (for now). The main reasoning is the following:

Settings and custom properties aren’t imported for the model elements. The reason is that the project dictates these settings and the elements are imported into an existing project with its own settings. Importing elements with different settings is cumbersome as the user should define settings from the top (project) down to elements (in the case of exceptions), and therefore should do so after importing elements only if it’s necessary for the project. Importing elements with settings makes the user to override these imported settings to the new context (the project), which should be automatic. The settings imported are valid for the source project, not necessarily for the target project. It’s an advanced setting which could be added in the future.

This is the reasoning behind why it's not present in the import system, which is the base of the copy/paste system.

It's a bit of a problem what to do: if we keep the settings/custom properties, and you don't want them in the new context, then you have to manually clean them up which is tedious. If you do want them, then you have to redefine them which is tedious too. the main advantage of the latter is however that (except for custom properties), interfaces and the like are assignable through rules which is the preferred way to do so, at the project level.

Even within the same project it's a problem as it can contain different derived models with their own set of rule based settings.

That said, from your PoV this all likely seems artificial and it should just work, and I agree. The main issue is how to determine when to do what. We already have different 'Paste' options, we could add some more, but it will then be a lot more per element, which also sucks.

At the moment there's little to fix as it works as intended. It's not ideal though, so we need to look at this in a future version, however I don't see a solution that will work for every situation automatically...

I'm struggling to think of an example of when you wouldn't want a non-inherited attribute, interface or namespace copied over. It maybe where angels fear to tread but for now I can get by copying a Derived Element by editing the project file in a text editor.

Copying an element between projects in different instances, or e.g. importing elements from another project (it's built on the import system after all).

You might need/want other elements defined on your entity/dto or none at all. This then requires you to clean them up after copying. That's a hassle too, so we opted for this.

In the situation where you copy one inside the same model, in the same instance, then there's little chance you'd want to have different elements, fully agreed. Hence we'll look into making the change in a future version to have more flexibility in this area, e.g. through an option which controls the default of this behavior (as there's no real solution which fits all scenarios). (btw copying an entity has the same behavior)