Frans,

I have built some templates which generate a new project with all the new code... BLOODY COOL TOOL... Sorry have to say that again... ^2

The only stumbling block I have now is how to get this new project to reference the other 2 LLBLGen projects.

I have copied the vsnet2003ProjectFileAdapter.template and created a new one for my new project. How can I get hold of the name and Project Guid / Package Guid of the other (previously generated) LLBLGen projects?

I'm trying to end up with:

                <Reference
                    Name = "Sds.ModernArk.Services.Ark.Data"
                    Project = "{83A1E5F6-55EF-497A-9261-1C7D894DBC70}"
                    Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
                />
                <Reference

                    Name = "Sds.ModernArk.Services.Ark.DataDBSpecific"
                    Project = "{00C1EF1E-2E44-418B-9C50-6E7B95BB1F7F}"
                    Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
                />

Obviously <[ProjectName]> refers to "this" project and I'm not sure if variables exist for the others projects in this content...

Any ideas ?

Marcus

Marcus wrote:

Frans,

I have built some templates which generate a new project with all the new code... BLOODY COOL TOOL... Sorry have to say that again... ^2

It finally shows the power of the generator framework

The only stumbling block I have now is how to get this new project to reference the other 2 LLBLGen projects.

I have copied the vsnet2003ProjectFileAdapter.template and created a new one for my new project. How can I get hold of the name and Project Guid / Package Guid of the other (previously generated) LLBLGen projects?

I'm trying to end up with:

                <Reference
                    Name = "Sds.ModernArk.Services.Ark.Data"
                    Project = "{83A1E5F6-55EF-497A-9261-1C7D894DBC70}"
                    Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
                />
                <Reference

                    Name = "Sds.ModernArk.Services.Ark.DataDBSpecific"
                    Project = "{00C1EF1E-2E44-418B-9C50-6E7B95BB1F7F}"
                    Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
                />

Obviously <[ProjectName]> refers to "this" project and I'm not sure if variables exist for the others projects in this content...

I'd go for DLL references, not project references. I'm not sure if you name your project's rootnamespace similar to the DAL rootnamespaces, but if you do, you can reconstruct the assembly name from that. As a last resort you could write a small class lib which loads the project file and grabs the project name/guid's and returns them via a method which you call from inside a template.

Otis wrote:

I'd go for DLL references, not project references.

Not sure I agree with that because when I re-generate, I want all 3 projects to refresh. And if I'm linked to a DLL, the Debug / Release configuration will be messy...

Otis wrote:

I'm not sure if you name your project's rootnamespace similar to the DAL rootnamespaces, but if you do, you can reconstruct the assembly name from that.

Yes I'm currently using:

<Reference
                    Name = "<[RootNamespace]>"
                />                              
                <Reference
                    Name = "<[RootNamespace]>DBSpecific"
                /> 

... to give me a reminder to manually add these references...

Otis wrote:

As a last resort you could write a small class lib which loads the project file and grabs the project name/guid's and returns them via a method which you call from inside a template.

Yes that is a last resort!!

Marcus wrote:

Otis wrote:

I'd go for DLL references, not project references.

Not sure I agree with that because when I re-generate, I want all 3 projects to refresh. And if I'm linked to a DLL, the Debug / Release configuration will be messy...

It doesn't matter if you reference a debug build dll in a release build project, as the real linking is done at runtime. So all it matters is that your code compiles. But if you keep them all together inside a single solution, it might be better to use project references indeed. The project file task performer doesn't put the GUID's in the task cache, so you can't grab them from there, but if you alter the sourcecode for that taskperformer, you obviously can add the GUID's (and other info) to the task-cache in the executingGenerator object, which you then can read in another task, for example your other project file generator task

Thanks!