Support SDK-style projects

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.

[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.

[Turhan8]

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