Wixsharp: Using PackageReference instead of packages.config doesn't appear to work

[jonreis]

Hello @oleg-shilo

I know you have covered this before, but I cannot get PackageReference to work properly with Wixsharp. I always get the error below. I have tried creating new setup projects from the Wixsharp templates, however; they all seem to use Package.config.

Any hints on how to solve this issue?

Severity Code Description Project File Line Suppression State
Error The "SetEnvVar" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with in the project file, or in the *.tasks files located in the "C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0Bin" directory. WixSharp Setup1 C:Usersjonre.nugetpackageswixsharp1.9.5buildWixSharp.targets 5

Steps to reproduce:

1) Remove the nuget packages from a wixsharp project
2) Delete your obj directory
3) Re-add the nuget packages and choose the option PackageReferences instead of Packages.config
4) Attempt to build the project

[jonreis]

@oleg-shilo I solved this by:
1) Checking SetEnvVar.dll into source control
2) Added to my csproj file.

Could you let me know if this is the recommended approach?

Thank you!

[oleg-shilo]

Well, not exactly :o)

For quite some time SetEnvVar.dll was a part of the build but because it was causing some problems with packages updates it has been removed and now WixSharp package relying on no external resources.

If you have problems with SetEnvVar.dll then most likely you are using older VS templates. Updating WixSharp project templetes extension will solve this problem. However... I just found that NuGet restore does not recreate the project structure the way it supposed to.

I am changing theist issue to BUG and will investigate it.

[oleg-shilo]

After some further digging I found that NuGet package is still invoking SetEnvVar MSBuild target. Thus fixing templates will only solve part of the problem.

The packages have been fixed (v1.9.5.1) and published. This will solve the problem of installing package on a brand new plain .NET project.

The templates fix is yet to come.

[jonreis]

@oleg-shilo as always thank you very much for your amazing library and help using it!

[oleg-shilo]

The VS project templates extension has also been fixed updated (v1.8.0):
https://marketplace.visualstudio.com/items?itemName=OlegShilo.WixSharpProjectTemplates

[jonreis]

Hi @oleg-shilo, I tried out the new templates (v1.8.0) and they are still using packages.config and placing dlls into the local project "packages" directory. However; if you use the new PackageReference mechanism the nuget packages get stored in the /.nuget folder.

It does seem to work for me if I use the PackageReference approach and only include (added by nuget automatically) in my csproj file.

    <PackageReference Include="WixSharp">
      <Version>1.9.5</Version>
    </PackageReference>

If I look in my obj directory there is a targets file that is automatically generated by Visual Studio. It contains:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>
  <ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
    <Import Project="$(NuGetPackageRoot)wixsharp.bin\1.9.5.1\build\WixSharp.bin.targets" Condition="Exists('$(NuGetPackageRoot)wixsharp.bin\1.9.5.1\build\WixSharp.bin.targets')" />
    <Import Project="$(NuGetPackageRoot)wixsharp\1.9.5.1\build\WixSharp.targets" Condition="Exists('$(NuGetPackageRoot)wixsharp\1.9.5.1\build\WixSharp.targets')" />
  </ImportGroup>
</Project>

So it appears that all the necessary targets are being pulled in and that I do not need to do anything in the csproj file. Is that correct?

To summarize, every things seems work without having to use the WixSharpProjectTemplates if you use the PackageReference approach. Are the templates for backward compatibility, or am I missing something? What is the minimum requirement in the csproj file for Wixsharp to function properly using the PackageReference approach?

[jonreis]

@oleg-shilo I think I must have closed this accidentally. Please see my comment above.

[oleg-shilo]

I think there is a bit of confusion about this issue. I need to explain....

The problem with *targets reference to _SetEnvVar.dll_ was areal problem and it is solved now.

Having nuget references as a packages.config is not a problem even though referencing the global packages from the project file is indeed a more attractive approach.

The real problem is that having project-listed packages does not play well with project templates. Despite my all effort was not able to find a solution when the template would allow project-listed packages. Furthermore, having project-listed packages prevents templates from being integrated with VS2015.

However if one starts with the plain C# console app then he can add nuget packages either way, globally or per project (_packages.config_)

[jonreis]

Ok, thanks for the explanation. Everything is working fine for me so I will close the bug.

[allknower]

Hello @oleg-shilo,
Can you explain, please, what is the right way to pass VS variables to wixsharp script now? I used SetEnvVar task before, but it was deleted from WixSharp package. I read comments in this issue and in https://github.com/oleg-shilo/wixsharp/issues/569 and, of course, I read wiki, but couldn't realize what should I do.

Thanks!

[oleg-shilo]

SetEnvVar was initially introduced to pass the location o the project folder. Though later it became apparent that it created more problems than bringing the benefits whan upgrading the package. Particularly because the location of the project folder may also be safely determined from the _current dir_ during the build. That's why it was eventually deleted from the solution.

But if you want to pass any sort of information into the project you can still red envars that you may set in the pre-build project events.

But if you want a complete flexibility then you can install WixSharp.bin package instead of WixSharp. This way tere will be no MSBuild custom task and building msi will need to be triggered from the post-build event by running the $(TargetPath) executable. And when you do that you can always pass any app arguments.