Book a Demo

Author Topic: .NET Framework model elements...  (Read 5830 times)

CleverCoder

  • EA User
  • **
  • Posts: 34
  • Karma: +0/-0
    • View Profile
.NET Framework model elements...
« on: April 25, 2008, 01:38:48 pm »
Good evening,

I was wondering if anyone had any suggestions to facilitate the usage and representation of .NET classes and elements in a diagram. The solution I currently have is to import assemblies from the GAC.. I was thinking maybe there is a more formal way to do this.

Any suggestions?

Best regards,
-Sean

 :o
-Sean

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: .NET Framework model elements...
« Reply #1 on: April 25, 2008, 08:55:56 pm »
Import binary module.
No, you can't have it!

CleverCoder

  • EA User
  • **
  • Posts: 34
  • Karma: +0/-0
    • View Profile
Re: .NET Framework model elements...
« Reply #2 on: April 26, 2008, 12:53:16 am »
Well... thats what I'm doing now.. Just kinda a pain to have to copy the assemblies out of the GAC and hand pick them..

Thanks for the reinforcement though!
-Sean

Emilio

  • EA User
  • **
  • Posts: 78
  • Karma: +0/-0
    • View Profile
Re: .NET Framework model elements...
« Reply #3 on: April 26, 2008, 01:13:17 am »
Tried the binary thing, it imports a LOT of things indeed. I filtered out a bit by selecting the "omit private members".

Basically I just need it so that I can reference these in my model as if they were "standard".

Another thing that is handy is to create a model author called "Microsoft" and assign that to all the imported elements. That helps in identifying them as part of the .NET Framework.

CleverCoder

  • EA User
  • **
  • Posts: 34
  • Karma: +0/-0
    • View Profile
Re: .NET Framework model elements...
« Reply #4 on: April 26, 2008, 01:54:57 am »
great ideas! Also, I found an easy way to pull in the assembly is to copy the full path from VS object browser and paste into the dialog box in EA. It works when usually you can't browse the GAC...

I like the Author trick.   :o

Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +1/-0
    • View Profile
Re: .NET Framework model elements...
« Reply #5 on: April 26, 2008, 04:21:56 am »
I like Emilio's ideas too. Introducing the "Microsoft" author is the obvious thing to do, only it didn't occur to me...
And omitting private members saves a lot of loading time.

It's still a lot of stuff though. I'll need a .Net Framework model very soon too, for referencing. We've got it all imported, but I don't like the idea of having to include the whole f-ing framework in every model. So I think I'll put the imported namespace packages under version control so that I can import (via GetPackage) the namespaces I need for each model.

Problem with this is that you create zombies (or stubs) when you import a package with elements which have references to elements in a package not previoulsy imported. These stubs are not being resolved when you import the package with the referenced elements afterwards. Meaning you had better import the packages in the right order, but to do so you have know the dependencies.

Some are obvious (everything needs System, System.Windows.Forms needs System.Drawing a.s.o.), but some are not. It would be a good thing to have a package diagram for the dependencies of .Net Framework namespaces, but as far as I know EA can search (or add to a diagram) all elements connected with a given element, but offers no method to search all packages containing elements connected with any element of a given package. Or does it?

Another shortcoming of EA is that it does not create components when importing binary modules. The much despiced Rational Rose created a component element for each DLL imported and assigned the classes therein to the component as realized classes. Whereas the classes created by EA on binary import contain the information which DLL they come from only in the Path property. With our own assemblies we stick to a "one assembly one namespace" rule to make things easier, but Microsoft doesn't.

Both problems could be overcome by writing an AddIn of course, but if I ventured to fill every gap in EA with an AddIn I would be writing AddIns for weeks on end instead of producing executable releases of software, and who would then pay my salary?
« Last Edit: April 26, 2008, 04:24:23 am by Frank_Horn »

Kevin G. Watson

  • EA User
  • **
  • Posts: 217
  • Karma: +0/-0
  • I love EVERYTHING including Microsoft
    • View Profile
Re: .NET Framework model elements...
« Reply #6 on: April 27, 2008, 04:44:38 pm »
Hi there....  [smiley=2vrolijk_08.gif]

I was under the impression that the Visual Studio Intregration thing would pull in the framework classes reference in ya project.... something like insert vs references

I can't check cos at mates terminal.

I rather liked Rose.... and almost adored the RT version, till I got Tau with Event and Message Activity animation.

....  does EA parse C# 3 stuff like

                        partial method / operation declarations    (EDM b3)

                        from... where... orderby.. select              (LINQ)

Kevin

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: .NET Framework model elements...
« Reply #7 on: April 28, 2008, 12:33:00 pm »
Quote
does EA parse C# 3 stuff like

                        partial method / operation declarations    (EDM b3)

                        from... where... orderby.. select              (LINQ)

Kevin
No.  Not yet.