Support SDK-style projects

[govert]

We want to support new SDK-style projects, where the NuGet packages will be included via <PackageReference> tags. This issue is to discuss how this might look.

• I'm OK for this to be a disruptive change, since I expect for an existing project to move to SDK-style project file is a disruptive change (though often simplifying). So I don't care about compatibility with the existing project layouts.

• I would prefer for this change not to impact either the runtime parts of Excel-DNA, or existing projects that are not SDK-style projects. I'm also not worried about old-style projects that use <ProjectReference> style, though it would be nice if these worked.

• I think the design should allow the current .dna file and ExcelDna.Build.props files to be removed, with sensible defaults + options to override and add in the project file.

• The output of the new build process will still be a .dna file (or files), but these will always be written by a build task.

• I'm OK (at least initially) supporting a subset of the current feature set that we get from .dna files + ExceDna.Build.props.

  • No need for runtime-compiled Projects, Source code or CustomUI support in the new-style project file.
  • References can then be replaced by a Packing directive, including a way to 'pack every .dll' (or Exclude / Include etc).
  • Similarly ExternalLibrary would have a sensible default (the project output) but can be modified explicitly.
  • Not sure how the ExternalLibrary list and the packing list would interact - they can be separate lists.
  • Maybe the 32-bit 64-bit outputs should follow the main project's TargetPlatforms if they are specified.
  • The packed output should be optional, and go into a separate directory (how to add extra files that could not be packed?)
  • The add-In name can be configured in the project file.

I don't think the debug settings in launch.json need to be handled by the build, at least not initially.

So as a first step, maybe this should be a valid add-in project (with no .dna file in the project inputs):

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ExcelDna.AddIn" Version="1.2.0-preview2" />
  </ItemGroup>

</Project>

For the Excel-DNA build this means:

• Build for both x86 and x64 platforms, into separate directories bin\x86\ and \bin\x64.
• The add-in will have the name <ProjectFileName>-AddIn.xll in both cases (??? or have different names or not have the suffix)
• The ExcelDna.xll and ExcelDna64.xll files are copied and renamed to the respective output locations
• A .dna file is created in the output directories, with the ExternalLibrary entry created and the Name filled in, from a template in the package.
• Packing runs with the output going to bin\x86\Packed\ and bin\x64\Packed\

Then further edits to the .proj file work like this (not sure I know what the best practices are here)

• TargetPlatform(s) is respected if only one of x86 and x64 are present.
• There is an extra <ExcelAddInName> string property that we understand.
• There is an extra <ExcelAddInFileName> or <ExcelAddInPath> string property that we understand.
• There is an extra <ExcelAddInMakePacked> boolean property that we understand (or some other way to switch packing on or off with a property'. Default might be on for Release, but off for debug?
• Maybe also <ExcelAddInPackFileName> <ExcelAddInPackedPath> for the packed output, default same as add-in but in \Packed subdirectory
• <ExcelAddInPack> property that works like Compile with Include / Exclude options. Default (if missing) might be all .dll files.
• <ExcelAddInInclude> or <ExcelAddInProcess> (maybe other name) property that determines the ExternalLibrary list written to the .dna file.

[augustoproiete]

Relates to Update ExcelDna.AddIn NuGet Package to support the new PackageReference format #193.

[cartermp]

The try-convert tool does support F# projects now: https://github.com/dotnet/try-convert/

It might be good to try running it on here just to see how close it helps move thigs forward. We've gotten some food feedback from folks that it wasn't perfect, but did a lot of the gruntwork so that moving to SDK-style was a lot easier.

Moving the codebase itself to SDK-style will also help force supporting using Excel-DNA as a package reference. Unfortunately, pulling in package references in non-SDK projects can be...problematic. It's best to just go full-on in converting this codebase and changing the packaging mechanism.

[govert]

@cartermp Thank you for the pointer. We have 'manual' support for SDK-style project files as is, so there is a workaround at least. This issue represents my current state to planning for the better(?) future, where the super-easy path works for SDK-style projects too.

I was really just grumbling about the old (.NET Framework) project templates for F# being changed recently, which means the easy path that used to work has suddenly stopped working - I'm not sure in which VS update this happened.

For Excel-DNA itself it is not a problem to move to SDK-style project files and I have done this in a private branch. The work really has to do with changing how the Excel-DNA NuGet package interacts with the Excel add-in project that consumes it, and making some build tasks around that. That might take some time.

[govert]

ExcelDna.Interop will need adjustment to work in PackageReference mode - it seems the COM interop embedding defaults or behaviour is different and we need to explicitly put the libraries into an embed directory, or something like that.

[PierreYvesR]

I have created a custom F# ExcelDNA template for dotnet new for my own use. It contains ".fsx" scripts that you can run from within VS to generate the debug settings - it's not as smooth at the regular ExcelDna options, but it gets you started. It's still a work in progress (the excel binary detection is just a placeholder) but it's already working. If you think it fits within ExcelDna github repo, I'm happy to create a PR. It's at github.com/WieldMore-io/WldMr.Excel.ExcelDnaTemplate for the time being,

[Turhan8]

Is it possible to also add image paths from sdk proj file into the dna file?