Как я могу заставить nuget (powershell) вставлять элементы <DependentUpon> в целевой файл csproj

Я пишу пакет nuget для службы Windows, идея состоит в том, что мои коллеги могут создать сервис Windows, устанавливающий пакет, и для них будут установлены все параметры ведения журнала по умолчанию, библиотеки entlib и другие задачи сохранения дома.

Я получил почти все, чтобы работать, кроме одной вещи, которая сводит меня с ума.

В папке содержимого моего каталога nuget у меня есть Service.cs и Service.Designer.cs, которые добавляются в целевой csproj, но они не связаны.

Когда я смотрю на файл csproj, я вижу:

<Compile Include="Service.cs">
  <SubType>Component</SubType>
</Compile>
<Compile Include="Service.Designer.cs" />

Но я хочу видеть:

<Compile Include="Service.cs">
  <SubType>Component</SubType>
</Compile>
<Compile Include="Service.Designer.cs">
  <DependentUpon>Service.cs</DependentUpon>
</Compile>

Любые идеи, уверен, что это будет связано с установкой install.ps script, но мои навыки powershell не существуют?

Как в стороне, может ли nuget использоваться для удаления/перезаписывания файлов? Пока что он просто пропускает.

Ответ 1

Ну, примерно через 2 дня powershell и msbuild ад, наконец, я получил рабочее решение. Смотри ниже. Слово предупреждения вызывает проект. Сохранение() имеет решающее значение - без этого вы получите предупреждение о конфликтующем изменении файла. Если вы вызовете project.Save(), сначала вам будет просто предложено перезагрузить решение, как только вы закончите.

param($installPath, $toolsPath, $package, $project)

#save the project file first - this commits the changes made by nuget before this     script runs.
$project.Save()

#Load the csproj file into an xml object
$xml = [XML] (gc $project.FullName)

#grab the namespace from the project element so your xpath works.
$nsmgr = New-Object System.Xml.XmlNamespaceManager -ArgumentList $xml.NameTable
$nsmgr.AddNamespace('a',$xml.Project.GetAttribute("xmlns"))

#link the service designer to the service.cs
$node = $xml.Project.SelectSingleNode("//a:Compile[@Include='Service.Designer.cs']", $nsmgr)
$depUpon = $xml.CreateElement("DependentUpon", $xml.Project.GetAttribute("xmlns"))
$depUpon.InnerXml = "Service.cs"
$node.AppendChild($depUpon)

#link the settings file to the settings.designer.cs 
$settings = $xml.Project.SelectSingleNode("//a:None[@Include='ServiceSettings.settings']", $nsmgr)
$generator = $xml.CreateElement("Generator", $xml.Project.GetAttribute("xmlns"))
$generator.InnerXml = "SettingsSingleFileGenerator"
$settings.AppendChild($generator)

$LastGenOutput = $xml.CreateElement("LastGenOutput", $xml.Project.GetAttribute("xmlns"))
$LastGenOutput.InnerXml = "ServiceSettings.Designer.cs"
$settings.AppendChild($LastGenOutput)

#set the settings designer to be autogen
$settingsDesigner = $xml.Project.SelectSingleNode("//a:Compile[@Include='ServiceSettings.Designer.cs']", $nsmgr)
$autoGen = $xml.CreateElement("AutoGen", $xml.Project.GetAttribute("xmlns"))
$autoGen.InnerXml = "True"

$DesignTimeSharedInput = $xml.CreateElement("DesignTimeSharedInput", $xml.Project.GetAttribute("xmlns"))
$DesignTimeSharedInput.InnerXml = "True"

$AGDependentUpon = $xml.CreateElement("DependentUpon", $xml.Project.GetAttribute("xmlns"))
$AGDependentUpon.InnerXml = "ServiceSettings.settings"

$settingsDesigner.AppendChild($autoGen)
$settingsDesigner.AppendChild($DesignTimeSharedInput)
$settingsDesigner.AppendChild($AGDependentUpon)

#fix up the project installer.    
$projectInstallerRes = $xml.Project.SelectSingleNode("//a:EmbeddedResource[@Include='ProjectInstaller.resx']", $nsmgr)
$projectInstallerResDepUpon = $xml.CreateElement("DependentUpon", $xml.Project.GetAttribute("xmlns"))
$projectInstallerResDepUpon.InnerXml = "ProjectInstaller.cs"
$projectInstallerRes.AppendChild($projectInstallerResDepUpon)

$projectInstallerDesigner = $xml.Project.SelectSingleNode("//a:Compile[@Include='ProjectInstaller.Designer.cs']", $nsmgr)
$projectInstallerDesignerDepUpon = $xml.CreateElement("DependentUpon", $xml.Project.GetAttribute("xmlns"))
$projectInstallerDesignerDepUpon.InnerXml = "ProjectInstaller.cs"
$projectInstallerDesigner.AppendChild($projectInstallerDesignerDepUpon)

#delete the bundled program.cs file.
$prog = $xml.Project.SelectSingleNode("//a:Compile[@Include='Program.cs']", $nsmgr)
$prog.SelectSingleNode("..").RemoveChild($prog)

#delete the bundled service1 file
$oldServiceFile = $xml.Project.SelectSingleNode("//a:Compile[@Include='Service1.cs']", $nsmgr)
$oldServiceFile.SelectSingleNode("..").RemoveChild($oldServiceFile)

$oldServiceDesignerFile = $xml.Project.SelectSingleNode("//a:Compile[@Include='Service1.Designer.cs']", $nsmgr)
$oldServiceDesignerFile.SelectSingleNode("..").RemoveChild($oldServiceDesignerFile)

#save the changes.
$xml.Save($project.FullName)

Бесстыдная самозагрузка: Я сделаю полную запись решения и проблем, с которыми я столкнулся в своем блоге cianm.com Надеюсь, что это кое-что поможет кому-то.

Ответ 2

Я думаю, что более простой способ сделать это (и, возможно, более поддерживается) через переменную $project, которая указывает на проект DTE.

Примечание. Я прихожу к этому через год, но сталкиваюсь с аналогичной проблемой. Я нашел этот ответ и начал его использовать, но у меня возникли проблемы с вызовом Save в конце PowerShell script - если бы у меня был установлен один пакет, зависящий от пакета с помощью PowerShell script, вызов Save "сломал вещи", чтобы другие пакеты не могли правильно установить. Во всяком случае, теперь я использую NuGet 2.5, но DTE не изменился с какой-либо значимостью с VS 2003, поэтому это должно работать даже в более раннем NuGet, который вы использовали.

param($installPath, $toolsPath, $package, $project)

# Selections of items in the project are done with Where-Object rather than
# direct access into the ProjectItems collection because if the object is
# moved or doesn't exist then Where-Object will give us a null response rather
# than the error that DTE will give us.

# The Service.cs will show with a sub-item if it already got the designer
# file set. In the package upgrade scenario, you don't want to re-set all
# this, so skip it if it set.
$service = $project.ProjectItems | Where-Object { $_.Properties.Item("Filename").Value -eq "Service.cs" -and  $_.ProjectItems.Count -eq 0 }

if($service -eq $null)
{
    # Upgrade scenario - user has moved/removed the Service.cs
    # or it already has the sub-items set.
    return
}

$designer = $project.ProjectItems | Where-Object { $_.Properties.Item("Filename").Value -eq "Service.Designer.cs" }

if($designer -eq $null)
{
    # Upgrade scenario - user has moved/removed the Service.Desginer.cs.
    return
}

# Here where you set the designer to be a dependent file of
# the primary code file.
$service.ProjectItems.AddFromFile($designer.Properties.Item("FullPath").Value)

Надеюсь, это поможет людям в будущем добиться чего-то подобного. Выполняя это таким образом, вы избегаете проблем с установкой зависимых пакетов, потому что проект сохраняется в середине установки пакета.

Ответ 3

Вот краткий пример с использованием Build.Evaluation, который является частью Visual Studio 2010 +

$buildProject = @([Microsoft.Build.Evaluation.ProjectCollection]::GlobalProjectCollection.GetLoadedProjects($project.FullName))[0]


$toEdit = $buildProject.Xml.Items | where-object { $_.Include -eq "Service.Designer.cs" }
$toEdit.AddMetaData("DependentUpon", "Service.cs")
# ... for the other files

$project.Save()