question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support SDK-style projects

See original GitHub issue

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.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:2
  • Comments:6 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
govertcommented, Jan 27, 2021

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

0reactions
Turhan8commented, May 10, 2023

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

NET project SDK overview
A project that references a project SDK is sometimes referred to as an SDK-style project. Available SDKs. The following SDKs are available: ID ......
Read more >
Moving to SDK-Style projects and package references in ...
The SDK style projects are the new format that first appeared for .net ... The new SDK style csproj only supports the new...
Read more >
Which version of Visual Studio supports SDK-style projects?
CMake has generators for different versions of Visual Studio (VS, e.g., VS 2017, 2019, etc.) Which versions of VS support SDK-style projects ......
Read more >
Is SDK style project the recommended approach for new . ...
Is the new SDK style the recommended approach for new .Net Framework projects? Or is it mostly used as a step on the...
Read more >
Demystifying the SDK Project - Dan Siegel
Dan Siegel - Building Better Apps - The new SDK Style projects really help make what's going on in the project system easier...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found