Yes 
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
