I encountered data redirection on Vista with LLBLGen templates for the first time earlier today. I discovered that a program sees one of two versions of a file stored under the Program Files folder, depending on its permissions level. See

http://www.microsoft.com/technet/technetmag/issues/2006/05/FirstLook/default.aspx (under Data Redirection)

and http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=724050&SiteID=1

So even though I copied my custom LLBLGen templates over the defaults that were installed, LLBLGen used the original templates and wiped out some custom code Thank goodness for SVN.

I also discovered that I could edit the templates in VS, after starting it with "Run as administrator", and have the changes reflected in LLBLGen.

I hadn't heard of this, so did you have the custom templates in your users directory?

There's little we can do about this. If the filesystem of the OS gives back file A and in reality it's file B, we can't know that.

Otis wrote:

There's little we can do about this. If the filesystem of the OS gives back file A and in reality it's file B, we can't know that.

I'm not disputing that point. But you're storing the templates under the Program Files directory, when Microsoft, for a long time, has really wanted settings stored elsewhere. You should at least move the editable content.

(edited)

paulshealy wrote:

Otis wrote:

There's little we can do about this. If the filesystem of the OS gives back file A and in reality it's file B, we can't know that.

I'm not disputing that point. But you're storing the templates under the Program Files directory, when Microsoft, for a long time, has really wanted settings stored elsewhere. You should at least move the editable content.

Oh, but the templates THERE are not really meant to be altered because they're templates which result in the generated code as we support it. They're data related to the system. The same is true for the dll's coming with llblgen pro, they're also installed there because they're not meant to be altered. If you want to overrule the templates with your OWN templates, you of course can do that without touching a file in program files.

Now, if you go load a project into the designer, and right-click the project node, select Properties.

At the top, you can select the additional templates folder and additional tasks folder. You can there specify a template and tasks folder where to check as well for templatebindings, template files and tasks files.

THERE you can specify for example to read the templates from a folder outside the program files folder.

If you want to alter the EXISTING templates, simply install llblgen pro in your own user folder and you're good to go. No-one forces you to install llblgen pro in the program files folder.

Btw, 'templates' aren't settings. Your settings are stored in your personal folder.

I know what Microsoft said about 'Program Files'. However, 'Program Files' is really a silly concept anyway. Users should install their software in their own folder, as it's done on OS X and unix. For WinXP etc. it didn't matter much, but under Vista it matters.

I know that because all of a sudden MS thinks 'Program files' is off limits, we now have to make sure that people can for example add their own plugins to the designer, stored in their own user folder. However, that's not going to work, as .NET's Fusion (assembly loader) can't load plugin's from folders that aren't in a pre-configured path in llblgenpro.exe.config, or better: can't load referenced assemblies which are referenced by assembly A when A is loaded manually, IF these referenced assemblies are in some random folder not pre-configured for fusion (e.g. in the llblgenpro.exe.config file, or in the GAC).

At the moment the designer doesn't have an additional plugins folder. I'll add that in v2.1, where we'll also use a non-Microsoft installer (NSIS based) to overcome the registry crap and the weird errors MS Installer service throws on vista. Though if the plugin references assemblies NOT in the GAC, the load will fail, simply because .NET can't find that assembly.

So the user is either obligated to do: - install llblgen pro in his/her own folder (preferred) or - place the plugin dll in the llblgen pro installation folder inside program files.

For a project-specific thing, like a typeconverter, this isn't a big deal, as the typeconverter can be placed in a folder relative to the project file, and for example be stored in a user folder.

For a designer specific element, like a plugin, it's different. It now comes down to the fact that the user has to place designer specific elements somewhere in the filesystem, and not inside the llblgen pro folder. As this is IMHO illogical, what people can do best on Vista is install LLBLGen Pro in their own user folder.

Reading about data redirection, I can't help it but think that this is bring more problems than it solves. For example... how is Windows going to determine that an installer runs? And what if I just want to unzip a file into a folder? (e.g. I want to install templatestudio into the llblgen pro folder). Does that work without redirection? I have no idea, though if it's not going to work, I need an installer just to copy a couple of files...

Otis wrote:

Reading about data redirection, I can't help it but think that this is bring more problems than it solves. For example... how is Windows going to determine that an installer runs? And what if I just want to unzip a file into a folder? (e.g. I want to install templatestudio into the llblgen pro folder). Does that work without redirection? I have no idea, though if it's not going to work, I need an installer just to copy a couple of files...

We need a wise developer able create a free vista extension that can, *) enable/disable this data redirection on the fly (maybe with a try icon or with hotkey combination) *) warn you when the operation you are doing result in a data redirection and, in that case, enable you to by-pass data redirection

I hope someone will develop a similar utility...

But, anyway, why install Vista at all? Whatever you do, you will be from 2% to 30% slower than on WinXP. (http://www.tomshardware.com/2007/01/29/xp-vs-vista/) Long life to WinXP