Namespaces with Visual Studio Link / Integration

[Oleg]

Hi,

When I assign (connect) a package to a VS project, the EA for some reason sets this package as a Namespace Root, destroying nested namespace chain . If I clear the Namespace Root, association with the VS project is cleared as well .

Are these options mutual exclusive? Isn't it possible to connect to a VS project while preserving a namespace hierarchy? Is there any workaround?

Thanks in advance
Oleg

[«Midnight»]

Check to see what happens if you change the namespace setting in your VS project. In particular, test this if you assign a namespace to a specific unit of code.

I suspect that the package is picking the namespace of the project over anything you've assigned in EA. This makes sense (in a way) if you think of VS as the 'master' copy, with EA taking directions from there.

If you think of the model as the master, then try creating the skeleton of your system in EA, then generating an initial code tree. Include namespace information. Now see if you can somehow get VS to import this as your project. [Note that I have not tried this; my last attempt was back in the MDG version 1 days, and the product has evolved. I'm about to evaluate version 3 'any day now' if I can find the time.]

Please let me know what you learn.

David

[Oleg]

Thanks David for the reply, but...

EA ignors the project's namespace as well as the model's upper nemaspaces. EA/MDG sets the package assigned to the project as the namespace root, then it preserves the sub-hierarchy.

Here is the example:
N1 - namespace root
+ N2 - assigned to a VS project with nemaspace N4
  + N3
    + C1

declaration of the C1 will be:
namespace N3
{
   public class C1
   {
   }
}

Any other ideas?

Thanks ant way,
Oleg

[«Midnight»]

No idea Oleg,

I hope to clear some time soon to evaluation version 3.0 of MDG Integration. If I come up with anything I'll post back.

David

[Oleg]

Thanks David any way.

[Eve]

A package connected via MDG is implicitly a namespace root, and as such the full namespace structure (as required for that project) should be replicated underneath that node.  (This is just how it works)

[Oleg]

Thank you Simon. That's what I thought

Such a "feature" forces design of a complicated application (built of multiple projects and deep namespaces) to look bulky and awkward.

Do you think there is a point in filing the feature request?

Thanks,
Oleg

[Mr. Sanders]

Hello Simon,

the problem is how EA handles VS projects/solution and build/run/test scripts.

They are bound to a package.
This is nonsens.

A package is a namespace node. And there is NO 1:1 relationship between a namespace node and a project/solution, because the namespace can embrace numbers of projects. Same for build/run/test.

EA is misusing the package for a logical managing unit.
This is wrong.

What would be correct?
I can give you a proposal.

Correct would be to attach the VS integration to a component.
Correct would be to attach run/build/test scripts to components.

A component results in a target, which can have a VS solution/project and build/run/test scripts.

Here we have a 1:1 relation ship.

And it would even be an ease to define a vs project in EA.

Just drag and drop the classes onto a component and EA could generate a VS project/solution for it with the side effect, that the namespaces of the logical package structure wouldn't be shivered.

Implemented in this way one could even reverse engineer/forward engineer exactyl the classes belonging to this component, which often makes more sense than reverse engineering  a namepsace node (but of course we need that too!).

Normally you work on 1 may 2,3 projects (components).
And what you want do generate/reverse engineer are the classes exatcly for these project/components.

That makes sense. Because other classes in the same namespace are (can be) involved with other projects.
So why should i want to generate/reverse engineer them?

Which sense makes it having a test script at a package level?
None!
Because you are not testing a namespace node!
You are testing a component!
You are building a component!
You are executing a component!
And you manage dlls and exes (components) in VS as projects.

This is the big error in EA, but I fear that they stay on their current philosphy attaching these things to a package.

This is definitly not a good thing to do it.

EA is corrupting our namespace stucture with it, because
nobody would have an overview which class is where in the package tree.

That's the reason we can not use the VS integration.
It's useless if you have to manage more that 5 to 10 targets.
We have more than 200!

Additionally we have to create unnecessary packages
only to support the EAs logic, that build/run/test scripts are bound to a package.

Please sparxians.
Rethink about this concept.
Have a look at rational rose.

Package structure -> logical structure
(no testing, no build script, no projects)

component structure -> physical structure
testing, running, building, projects

That's the way what makes sense and that does not corrupt the model with artificial/unnecessary things.


Michael

[Oleg]

Agree, even twice!

* With such an approach the MDG Link / Integration is useful only for toy projects, it becames useless for real ones
* The approach that Rose took is much more "Rational"

Thank you Michael,
Oleg

[Mr. Sanders]

Hello Oleg,

I hope you mean current, when you say 'such'.

Michael

[Oleg]

Sure - the current solution. Sorry.