ApplicationInsights.config not copied to bin

[TimothyMothra]

Problem: ApplicationInsights.config defaults to "CopyToOutputDirectory = Never". We are unable to change this property to "PreserveNewest" which would be ideal.

This bug was introduced when we converted to PackageReference style projects (2.9-Beta2). TelemetryChannel was always doing this without being noticed. Most users onboard via Web repo which is affected. I compared the nupkgs of 2.9-Beta2 and 2.8.1. There is no metadata included in the package that sets this property so it's unknown why the difference exists.

Immediate User Workaround: Manually set property on ApplicationInsights.config "Copy if newer".

Permanent fix: Introduce a targets file that copies the config during build. We would add this file to any project that introduces the config file to a project.

Questions:

• Should we add a switch to disable this? I'm not opposed to this, but what is the customer need to do so.
• ~If a customer has multiple packages with this target should we check that this task was already executed and prevest duplicate executions?~ This is not needed because the Target name is identical across packages and won't be executed twice.

[TimothyMothra]

AH-HA!!

I found out what changed!!

The WindowsServer project had an install.ps1 that got removed during the conversion to PackageReference.

This script ONLY existed in the WindowsServer repo. Because we suggest that users onboard via the Web package, Web installs WindowsServer which would execute this script.

There is guidance from the NuGet team to avoid using install.ps1 scripts because they only work via VisualStudio package installs, and do not work via command line. Now that I know the real cause, I'm investigating if there is a different recommended approach.

Edit:

Per https://github.com/NuGet/Home/issues/6330 install.ps1 is no longer supported and there is no workaround.

Per https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html, init.ps1 might be supported.

I can test this alternative tomorrow.

Will existing NuGet packages work if I am using PackageReference for WPF, Windows Forms or ASP.NET projects? While we have done a lot of work to ensure that existing packages on NuGet.org just work with the PackageReference format, there are a few scenarios that will not be supported in the PackageReference world and might impact your ability to migrate away from packages.config. Some examples of scenarios that will not be supported include content folders (we have introduced ContentFiles), XDT transforms, PowerShell scripts i.e. install.ps1 and uninstall.ps1 (only init.ps1 is supported) . If you come across a package you consume in your WPF or Windows Forms app that worked previously but does not work on migrating your project to PackageReference, we would love to hear from you, so that we can investigate what the incompatibilities might be.