| Dion@sorna.com |
| Newbie |
|
| Eagan, MN |
|
|
| None Specified |
|
| Thursday, September 17, 2009 |
| Monday, November 2, 2009 4:41:36 PM |
4
[0.02% of all post / 0.00 posts per day] |
|
Quote:Did you remove those projects from one solution, create a new, empty second solution and used "Add|Existing Project..." to add those projects?
Yes.
Quote:How did you try to recreate them?
There (thankfully) weren't many tests nor test lists so I did this manually through the VS Test List Editor. I recreated them by right clicking on the "Lists of Tests" item in the Test List Editor and selecting "New Test List..." from the context menu.
Quote:Maybe you can send a short sample to our support center, that we can reproduce it?
I regret that I did not preserve the project/solution files from when things were in their malfunctioning state. I can state that there was nothing unusual or special about the projects/solutions/test lists. Everything was quite ordinary. The new solution consisted of one .NET v2.0 library project, one .NET v3.5 Visual Studio unit test project, one UModel 2009 project. The original and the new Visual Studio solutions reside in different locations on the file system. The project names remained the same. UModel did not appear to have any problems updating the model to reflect the file system changes.
Quote:PS: When I understand correctly, now everything is working for you again!?
Correct. By removing the UModel project whatever the problem was, it was allowed to be reset/corrected so that test lists could be created and saved without problem. Adding the UModel project back into the solution did not alter the correct functioning of Test List Editor.
|
I can confirm that this is indeed a bug that is somehow tied to UModel.
In our case we migrated a class library project and it's associated unit test and UModel project into a separate dedicated solution.
Upon doing so our unit test lists disappeared from the list editor window though the associated vsmdi files remained. I attempted to recreate them. Upon clicking "ok" to create the test list I would receive the same "The parameter cannot be null or empty. Parameter name: filename" alert dialog. The vsmdi file would be created and the test list was added to the editor window where it could be worked with. Opening and closing the solution however, would result in the test list editor losing the test lists. Repeating the process yielded the same results.
By removing the UModel project I was able to successfully recreate the test lists without incident. I then added the UModel project back into the solution. Creating subsequent test lists also worked without incident.
System:
* Vista SP2
* Visual Studio Team System 2008 v9.0.30729.4108
* .NET v3.5 SP1
|
The "use namespace for code file path" is precisely what I'd like except that the legacy coding standards to which I am constrained on certain projects dictate rules that don't follow the Java methodology. By that I mean that each project within a solution should not contain the full directory tree in a perfect mirror of the namespace hierarchy. Rather, if a project (say "ProjectA") in a VS solution was assigned a root namespace of Company.ProjectA and was located on the filesystem at "D:\Team Server\SolutionC\ProjectA" then the fully qualified class named "Company.ProjectA.FeatureB.MyClass" should be placed within the file system as "D:\Team Server\SolutionC\ProjectA\FeatureB\MyClass.cs". However, with the "use namespace for code file path" option turned on the class will be emitted at "D:\Team Server\SolutionC\ProjectA\Company\ProjectA\FeatureB\MyClass.cs".
If I were to reverse engineer an existing project UModel would figure things out and map files to model correctly. However, should I model a new class in UModel it will create a new, full directory tree within the project directory beginning with the root namespace rather than the existing directory structure. This means that I have: "D:\Team Server\SolutionC\ProjectA\FeatureB\ExistingClass.cs" and "D:\Team Server\SolutionC\ProjectA\Company\ProjectA\FeatureB\NewClass.cs".
I hope this is a bit clearer.
Thanks,
--Dion
|
Ideally I would like to be able to generate code from models such that files are organized in directories according to namespaces. However, I only wish to generate directories relative to the project namespace.
For instance, if I had a fully qualified class: "Company.Common.Project1.MyNamespace.MyClass"
The Visual Studio solution encompasses everything within "Common" the project's root namespace would be "Company.Common.Project1".
Code generation for the Project1 component (project) would emit directories relative to "Project1". If the project were located at:
"D:\Team Server\Common\Project1" then the class source file would be emitted at: "D:\Team Server\Common\Project1\MyNameSpace\MyClass.cs"
I can "sort of" accomplish this by turning off the "use namespace for code file path" feature then and then defining separate components with assigned directories. However, the source files are not associated with the project in question. Moreover, when I manually associate the file with the existing project the realization association between class and sub-component are replaced with one between the class and the parent.
The only means of accomplishing what I want is to first create the Visual Studio class source file and let reverse-engineering model the relationship for me. Workable but not convenient.
Please advise.
Thanks,
--Dion
|
|
