locked
MSBuild SafeImports reg entry question RRS feed

  • Question

  • I found the following regkey:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\MSBuild\SafeImports

    which allows me to add my foo.targets file so VS won't whine about not trusting the targets file.  Can you use just the filename in this entry?  Right now everything is specified by a full path.  However, that gets tiresome when using VSTS because when we create branches the path to the target file changes e.g:

    C:\Projects\Foo\Trunk\Build\Foo.targets
    C:\Projects\Foo\Branches\1.0\Build\Foo.targets
    C:\Projects\Foo\Branches\1.1\Build\Foo.targets

    Anytime we create a branch we have to remember to go much with the registry - not ideal.  It would be nice if you could just specify "Foo.targets" and have VS 2005 not complain about Foo.targets in whatever path is used.  Or perhaps a comprise would be to specify something like "C:\Projects\Foo\**\Foo.targets".  Then any Foo.targets that appears anywhere under C:\Project\Foo would be accepted.
    Wednesday, June 8, 2005 11:47 PM

Answers

  • Good point. I've opened a bug internally to consider this.

    Our first concern is security -- if people typically put just "foo.targets" then I just need to send you a project along with a damaging version of foo.targets that it imports and I could damage your computer when you load it.

    (The reason we have to have this list is that we only scan projects for load-time safety, not any targets they import. Targets files just have to be on the list.)

    Your recursive suggestion might be safe enough, though. What we have right now doesn't really support a tree that has lots of "makefile.inc" equivalents throughout it.

    Dan
    Thursday, June 9, 2005 6:16 PM

All replies

  • Good point. I've opened a bug internally to consider this.

    Our first concern is security -- if people typically put just "foo.targets" then I just need to send you a project along with a damaging version of foo.targets that it imports and I could damage your computer when you load it.

    (The reason we have to have this list is that we only scan projects for load-time safety, not any targets they import. Targets files just have to be on the list.)

    Your recursive suggestion might be safe enough, though. What we have right now doesn't really support a tree that has lots of "makefile.inc" equivalents throughout it.

    Dan
    Thursday, June 9, 2005 6:16 PM
  • "What we have right now doesn't really support a tree that has lots of "makefile.inc" equivalents throughout it."

    Yeah the other missing hole WRT supporting multiple branches is some sort of instrinsic MSBuildImportProjectFullPath property.  You have a property to the top level MSBuild project file, unfortunately these can occur in multiple places in the directory structure so basing relative paths off this property just doesn't work. 

    OTOH, target files (or another project like AnchorMyLocation.proj) that could reference a MSBuildImportProjectFullPath property could then establish an anchor directory upon which all other relative paths could be based off of.  This stuff becomes really important when you start building multiple branches.  Right now I have my project files using an EnvVar with an absolute path - that won't work in the multiple branches scenario.  I think I'll create a custom task that essentially just uses Type.Assembly.Location to find the location of the custom task assembly in order to establish that anchor point for relative paths. 

    BTW, thanks for all your help in getting me over various humps!
    Thursday, June 9, 2005 8:42 PM
  • Maybe you're interested in how we do this building VS. In the "settings" targets for building VS, we have this line near the top:

    <EnlistmentRootPath Condition="'$(EnlistmentRootPath)' == ''">$(_NTDRIVE)$(_NTROOT)</EnlistmentRootPath>

    all tools are located relative to this. In other words, we use these 2 environment variables internally. This works fine as long as you have one set of tools, as you point out. The env vars are automatically set by a batch file called "razzle". When a developer has multiple branches on his machine, I believe they create multiple razzle shortcuts, one for each branch, that set _NTDRIVE and _NTROOT correctly. So that's how we get it to work. Arguably the multiple shortcut approach is a little lame, but we have done it that way for years.

    If MSBuild had $(MSBuildImportProjectFullPath), I suppose we could get rid of these environment variables and shortcuts, as you point out, and building any project would just do the right thing. Each of the zillion projects actually finds their targets files using these same environment variables and they would have to be changed to use relative paths, but that's not hard. I'm still not sure whether we would change though, because we have other uses for these "razzle" batch files -- they set up various other global build and debugging settings.

    Anyway, I can see the utility, and I've opened up a suggestion for it. We have considered it a year ago and cut it due to time concerns, but we'll see.

    Dan

    Friday, June 10, 2005 4:27 AM
  • FYI, I posted a suggestion about digitally signing project files.  It could be a handy way to satisfy VS's security concerns.  Digitally sign your project file with a strong name key pair (or perhaps a cert) and then tell VS that any project file with a certain pubkeytoken is OK to load.
    Saturday, June 18, 2005 5:50 PM