This project has moved and is read-only. For the latest updates, please go here.


Have multiple projects share a common/linked Config.ps1


I've got multiple projects in a solution, and I've been using linked files to control Version information ( ). I'm trying to apply the same general idea to this.
  • Copy Config.PS1 to solution level. (D:\My Solution\Config.ps1)
  • Remove Config1.ps1 from project. (D:\My Solution\Project1_CreateNewNuGetPackage\Config.ps1)
  • Add exiting item to project => Navigate to common version => "Add as link".
  • Project now contains a "linked" version to the solution file. Any changes to solution file affect all versions.
This works very well for Assembly information (Company, Version, File version, etc) and I was hoping to extend it to this project. If I have 8 projects in a solution, and I want to update all 8 of them to "$versionNumber = 1.0.8", do I update 8 files? or just 1? Prefer: 1.

The build script isn't pulling information from the linked configuration file.

Is there a way to work with the Linked files? Search up the directory tree until it finds a Config.ps1? Define a location in the Config.ps1 file? Define a common file path in an alternate config file (ConfigCommon.ps1: $commonConfigFile = "D:\Config.ps1")?

Is there a way for this script to pull D:\Config.ps1... then D:\MySolution\Config.ps1... then...? nuget pulls config information from D:... then D:\MySolution... and further up the chain, each step adding too/overwriting the previous step.
Closed Apr 13 at 7:15 AM by deadlydog
Closing due to lack of response and I provided easy work-arounds for all of the issues mentioned.


deadlydog wrote Jul 16, 2014 at 5:41 PM

Hi WernerCD. Is it just the version number that you want all of the NuGet packages to share? Since you are already using a linked/shared AssemblyInfo.cs file (so your projects already share a version number), simply leave the $versionNumber variable blank in the Config.ps1 files of each project and all of your packages will use the project's assembly version, so they will all be the same.

If you still want to use one Config.ps1 file for all projects, I would delete the Config.ps1 file from all projects except one, and then add them back in as a link to that one remaining Config.ps1 file. Your other option is to modify the $CONFIG_FILE_PATH variable in the DoNotModify\CreateNuGetPackage.ps1 and DoNotModify\UploadNuGetPackage.ps1 files in each project to point to wherever your "shared" Config.ps1 file is at (i.e. up at the solution level as you suggested).

Your last suggestion of having a Config.ps1 hierarchy is interesting, and would actually be super simple for you to implement. Basically you would just create your CommonConfig.ps1 file as a copy of the Config.ps1 file, and then at the top of each of your Config.ps1 just dot source the CommonConfig.ps1 file in.

e.g. . D:\CommonConfig.ps1

So this would pull in all of the variables defined in the CommonConfig.ps1 file. The trick is then just to make sure you don't overwrite the values defined in CommonConfig.ps1 in the Config.ps1 files. This would simply involve changing the variables in the Config.ps1 file from:

$versionNumber = ""


If the version number is not already defined in CommonConfig.ps1, define its value here.

if (!(Test-Path Variable:Private:versionNumber) -or (Test-StringIsNullOrWhitespace $versionNumber)) { $versionNumber = ""; }

The Test-StringIsNullOrWhitespace function is declared in the CreateNuGetPackage.ps1 and UploadNuGetPackage.ps1 files, and should be available at run-time by the time the code in the Config.ps1 file gets executed.

Hopefully this answers all of your questions and gets you going. At this time I don't think I'll make any changes to the NuGet package, as I don't think too many people will require this functionality and I don't want to complicate the Config.ps1 file for a feature that most people won't use, especially when it's fairly easy for you to implement yourself. If I get more requests for it though I'll reconsider.

Let me know if this gets you going or if you still have questions/problems.

WernerCD wrote Jul 17, 2014 at 3:16 PM

Never would have thought of simply "dot sourcing" as you call it. I'll have to try that.

My attempts to create a hierarchy were more because of the other issue I created (SL5 not pulling), but that might be simple enough to work in its current form.

let me try this out and I'll let you know what I encounter.