Frans,

I have been cleaning up my solution and project files recently and have a suggestion which might make project maintenance easier:

Currently LLBLGen generated projects reference the runtime libraries in C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries... This is a bit of a pain for a couple of reasons:

1) Only builds on a machine that has LLBLGen installed. The license is only required for the code generator, so source should be capable of being built on another machine, like a dedicated build server.

2) If put the source tree into source control, you don't have all the files needed by the project to build in the source tree, and therefore in source control. This is especially true for custom templates, which is another issue for source control...

3) If you put a solution into source control, then later upgrade LLBLgen and then pull it from source control again later, which can happen when you need to perform maintenance on the project... you may end up with regression issues and because the build of LLBLGen has changed. I would prefer to keep the original runtime libraries and upgrade projects only if required.

I was thinking that newly generated projects should copy the current runtime libs to a folder called "lib" which is under the main source three. I also think that if custom templates are used for the generation process, these should also be either copied to a folder under the source tree or be capable of being saved there permenantly.

I personally like the idea that everything I need to build (including a full code generation) should be resident under a single source top level folder. This way I can be sure that if the folder contents are in source control, then I have "everything" I need in SC. Also from a backup point of view, this works better also.

I recently has to give out my source tree to an external dev so that they could work on the presentation tier and had big problems getting the solution code to build on his machine... (he didn't need to regenerate the code).

I have since manually "fixed" all these project reference issues, but just thought I'd put my thoughts here so that they might be considered for a future product enhancement...

Thanks for your ideas on this Some developers indeed work like this, others work differently, it's a matter of taste I think. The problem indeed is: you can't configure it now, it's doing it one way, not the other way.

I'll add it to the list for v2.0, which will have easier ways to setup a task chain in the designer, so you can setup the tasks manually, for example, add a filecopy task.

The one problem I have with your setup is that when a fix is released for the runtime libraries, you have to manually update the files, and if you simply compile against the latest runtimes in your installation folder, you won't have a problem.

Otis wrote:

Thanks for your ideas on this Some developers indeed work like this, others work differently, it's a matter of taste I think. The problem indeed is: you can't configure it now, it's doing it one way, not the other way.

I think the main gist of what I was saying is to be able to know that you have everything you need in source control, rather than having a situation where you have some files from here and some files from there... Its easy to make mistakes and leave something out. The only time you realise is a year later when you try to build again and nothing works.

Otis wrote:

The one problem I have with your setup is that when a fix is released for the runtime libraries, you have to manually update the files, and if you simply compile against the latest runtimes in your installation folder, you won't have a problem.

This is probably the big project vs small project dilema... For a big projects you don't want things to happen automatically as you loose control (suddenly you have to regression test 50+ projects) , for smaller projects having to do things manually is a pain!

For me if there is a fix, I simply close VS.NET, drop the new DLL into the lib folder, run a script which deletes the bin and obj folders within the source tree and open VS.NET again. Everything is then updated.

The big difficulty I'm having at the moment is whenever the source is pulled from SubVersion onto a different machine or when the source path is different, like for instance when I branch. If I include the csproj.user files in source control, the path to the lib folder still points to the previous mainline's lib folder (as this absolute path is stored in the .csproj.user file) and the relative paths defined in HintPath attributes of the .csproj which point to the CORRECT lib folder are ignored.

Does anyone have any idea how to overcome this VSNET "bug"?

I've just found the following Registry key which would explain why my hint paths for LLBLGen are being ignored...

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\AssemblyFolders\LLBLGenPro.RuntimeLibraries.Net11

now to track down the others!!!

Marcus wrote:

Otis wrote:

Thanks for your ideas on this Some developers indeed work like this, others work differently, it's a matter of taste I think. The problem indeed is: you can't configure it now, it's doing it one way, not the other way.

I think the main gist of what I was saying is to be able to know that you have everything you need in source control, rather than having a situation where you have some files from here and some files from there... Its easy to make mistakes and leave something out. The only time you realise is a year later when you try to build again and nothing works.

Yes, good point. Also, if your code works with one version and has to be on that version, and you upgrade your installation, the code you've developed has to keep on working with the old(er) version.

Otis wrote:

The one problem I have with your setup is that when a fix is released for the runtime libraries, you have to manually update the files, and if you simply compile against the latest runtimes in your installation folder, you won't have a problem.

This is probably the big project vs small project dilema... For a big projects you don't want things to happen automatically as you loose control (suddenly you have to regression test 50+ projects) , for smaller projects having to do things manually is a pain!

For me if there is a fix, I simply close VS.NET, drop the new DLL into the lib folder, run a script which deletes the bin and obj folders within the source tree and open VS.NET again. Everything is then updated.

True I'll make it as flexible as possible. The tool's first goal is to help people, so that's what it should do, not getting in the way, like a regular VS.NET feature

Marcus wrote:

I've just found the following Registry key which would explain why my hint paths for LLBLGen are being ignored...

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\AssemblyFolders\LLBLGenPro.RuntimeLibraries.Net11

now to track down the others!!!

I think this is the Reference Path. It is a project property. VS Seems to look in these paths ignoring the hint path in the project. However, if you delete you reference paths when you do a build it will add reference paths back in using the hint paths in the project.

To me this is wrong. I think when the IDE builds the project/soultion it should use the hint paths first, and only if it can't locate the files there should it use the reference paths.

I understand why the IDE has them, so each person can store referenced binaries wherever they like. But, I also feel this is not practical. When you work on a team you generally all put the project and refernced files in the same place.

I do as you do. I have a version manager project folder named ThirdPartyDLLs. All of the project hint paths point to this folder. This allows the build machine, which doesn't use the IDE to build fine using the checked in DLLs. If a shared DLL updates we just check it into the project and future builds use this version.

Marcus wrote:

The big difficulty I'm having at the moment is whenever the source is pulled from SubVersion onto a different machine or when the source path is different, like for instance when I branch. If I include the csproj.user files in source control, the path to the lib folder still points to the previous mainline's lib folder (as this absolute path is stored in the .csproj.user file) and the relative paths defined in HintPath attributes of the .csproj which point to the CORRECT lib folder are ignored.

Does anyone have any idea how to overcome this VSNET "bug"?

Well, first of all DON'T source control .user files. this will cause all types of problems. As I said above, if the new version project is the same solution/project name you are going to have to delete the reference paths for the projects, then the build will pick up the hint paths from the project.

HTH, BOb

pilotboba wrote:

To me this is wrong. I think when the IDE builds the project/soultion it should use the hint paths first, and only if it can't locate the files there should it use the reference paths.

Yes I totally agree... The HintPath should be used first.

pilotboba wrote:

Well, first of all DON'T source control .user files. this will cause all types of problems. As I said above, if the new version project is the same solution/project name you are going to have to delete the reference paths for the projects, then the build will pick up the hint paths from the project.

Yes .user are no longer in source control and I have everything building fine. The only remaining issue which is now partially resolved is when I create a "branch". The branch is created in a different place on my hard drive than the "trunk". For web projects this is a pain as the IIS virtual directory is now pointing to the wrong place...

I wrote a small script which I can double click and it deletes the existing virtual directories and recreates them to point to the current folder path. This seems to work well as each time I pull the source I simply double click the script before I open the solution in VS.NET.

The only remaining problem is that "somewhere" the old path to the virtual directory is retainded by VS.NET, and I'm asked to "Retry" and I have to enter the new path again manually (the first time VS.NET opens the solution). Has anyone found where this path is being cached?

Marcus

Marcus wrote:

I wrote a small script which I can double click and it deletes the existing virtual directories and recreates them to point to the current folder path. This seems to work well as each time I pull the source I simply double click the script before I open the solution in VS.NET.

The only remaining problem is that "somewhere" the old path to the virtual directory is retainded by VS.NET, and I'm asked to "Retry" and I have to enter the new path again manually (the first time VS.NET opens the solution). Has anyone found where this path is being cached?

Are you changing the web path? If so, this is stored in the .webinfo file.

BOb

pilotboba wrote:

Are you changing the web path? If so, this is stored in the .webinfo file.

No the web path remains the same, but the physical path changes... VS.NET seems to cache the previous physical path and tries to use it (the old path) when opening the web project.