NET project namespace

Hi VP,

I am currently evaluating your DB-VA Professional product (VP_Suite_Windows_3_1_sp1_20071012) to generate C# code for .NET.

Can I set somewhere the “Project Namespace” when generating a NET project?

If the DB-VA model namespaces are:
name1
name1.sub1
name1.sub2
etc…

The final (C#) namespaces should be:

MyNamespace.Tests.name1 (files in name1 folder)
MyNamespace.Tests.name1.sub1 (files in name1\sub1 folder)
MyNamespace.Tests.name1.sub2 (files in name1\sub2 folder)

I tested adding the default namespace to the DB-VA model, this way:
MyNamespace.Tests.name1
MyNamespace.Tests.name1.sub1
MyNamespace.Tests.name1.sub2

But then, the generated files are namespace correct, but placed in folders:
MyNamespace\Tests\name1
MyNamespace\Tests\name1\sub1
MyNamespace\Tests\name1\sub2

BTW, the project namespace is left as “”…

If I change the project namespace to “MyNamespace.Tests” is all ok, but they are warnings about the location of the files (should be in name1, name1\sub1, …).

So, the “project namespace” should only be added to the class full qualified name, but the folder hierarchy left as the original DB-VA model.

Is it possible?

I have also test setting “root” to the “MyNamespace” namespace in the model, and then all the reaiming namespaces as “Leaf”, but with no luck :?:

Anyway, what the “Root” and “Leaf” mean for the namespaces? I can’t find a clue in the help nor in the PDF file :?:

Many thanks

I forgot to say that I want my project base namespace to be just this: “MyNamespace.Tests”. And then the namespaces defined in the DB-VA model to be appended to this base namespace.

Sorry for the misunderstanding

Hello distansia,

We are now checking this issue. Will come back to you as soon as possible.

Best regards,
Jick

Hello distansia,

Do you want to generate code like defined in MyNamespace.Tests.sub1, but the files are saved to sub1?

Best regards,
Jick

Yes :smiley:

Well, first of all, I must say this is not really an important issue. I only tell you as a “nice to have” feature. This is not really a bug.

But I will be more precise about what I am trying to tell:
In the first image, you can see the “Default namespace” setting in Visual Studio 2005 IDE. Generated ORM Code leaves this field empty, so all packages defined in the DBVA model transform in the corresponding namespace in VS project.

I mean:
DBVA model [pack1.sub1] —> VS namespace [pack1.sub1]
Files located in \pack1\sub1*.*

First, the problem:
If you want to use your generated ORM code as a DLL file, and then add a new WindowsApplitacion project to the VS Solution, you are forced to put a “Default namespace” when creating it within the IDE ("" is not allowed). Let’s say you put “name1” ( maybe more typical default namespaces being . )
(see second image)

So, your classes in the WindowsApplication project will be on name1.pack1.* while the orm classes are on the pack1.*

1st attempt to solve this:
Put “name1” as default namespace in the ORM project.
→ No way, the classes are still in the pack1.*

2nd attempt:
Refactor the DBVA model and include the “name1” package as the first one, and move all others inside it.
→ It works! All your classes are on name1.pack1.* namespace!
→ Side-effect: The physical folder structure now has one more item: All the .cs files are moved to \name1\pack1*.
→ Side-effect: If you put “name1” as the default namespace in the ORM code, the compiler emits warnings about files not in the right physical folder structure (avoided by disabling this warning, no problem)

3rt attempt:
Do the same as 2nd attempt, and then on the VS IDE, after setting “name1” as default namespace, move all folders inside “name1” folder to root folder of the project.
→ Fantastic! all right by now. Namespaces are correct, folder structure is correct. No warnings, no complaints.

Well, as you can see this “feature” has a nice solution. The only drawback here is that you have to do manually all this steps (or better, build a NAnt task and run it) everytime the ORM code is generated.

Cons:

  • Moving a lot of folders inside “name1” to root project folder is time-consuming (in the IDE)
  • If you have included to the project some handmade “partial class” files to improve the ORM classes, you will have some warnings when moving the folders inside “name1” to root. Nothing dramatic, but again click here, click there (time consuming)

What can DBVA do to help reduce this “fix-the-orm-code” time?

Let the user set the “Default namespace” when generating code to Visual Studio project, then generate the files as:

  • namespace name1.pack1.* { … }
  • All the references set to name1.pack1.* (well, global::name1.pack1.*)
  • put the files in \pack1.* (not \name1\pack1.*)
  • finally generate the .csproj file (the project file) with the RIGHT path of the files (\pack1.*)

In real world, this can be setup as a NAnt task, moving the \name1\pack1*.* folders to \pack1*.* folder and fixing the generated .csproj file.

I think this will speed up the time spent during the “change something in the design” and “rebuild already existing VS solution to test the changes”.

But, again, this is not a bug in the software. Just a “nice to have” feature to improve it.

Many thanks for reading this loooong post :roll:

namespace.png

namespace2.png

HI distansia,

Let me discuss with our team first. I will get back to you as soon as possible.

Best regards,
Jick

Hi Jick. In the meanwhile I have sent to the forum the NAnt build file I am currently using to fix this little problem with the namespaces.

http://forums.visual-paradigm.com/posts/list/2612.html

In addition, I use it also to add some extra files to the generated .csproj file and mark some ORM classes as partial because I have already wrote some partial classes extending your ORM generated ones and the compiler showed errors if no “partial” was set in the affected ORM classes.

Excuse my fast explanation (not very clear), all the details are on that post.

Bye :slight_smile: