Support SDK-style projects
See original GitHub issueWe 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\
andbin\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 likeCompile
with Include / Exclude options. Default (if missing) might be all .dll files.<ExcelAddInInclude>
or<ExcelAddInProcess>
(maybe other name) property that determines theExternalLibrary
list written to the .dna file.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:6 (4 by maintainers)
Top GitHub Comments
@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.
Is it possible to also add image paths from sdk proj file into the dna file?