C#•3y ago

Packaging a non-C# binary into a NuGet package.

So I've been optimizing this logging library of mine to try to get it as fast as I can. with the main bottleneck appearing to be as fast as it can be I just wrote the main functions of it in Rust and decided to interop it in. this showed to give a rough ~50ms improvement on benchmarking but now I don't know how to package this thing really... In the C# section it roughly looks as so:

[DllImport("print.dll", CharSet = CharSet.Ansi)]
static extern void print(IntPtr input, IntPtr filePath, bool isInfo, uint lineNum);
[DllImport("print.dll", CharSet = CharSet.Ansi)]
static extern IntPtr formattedLog(IntPtr input, bool isInfo, IntPtr filePath,  uint lineNum);

[DllImport("print.dll", CharSet = CharSet.Ansi)]
static extern void print(IntPtr input, IntPtr filePath, bool isInfo, uint lineNum);
[DllImport("print.dll", CharSet = CharSet.Ansi)]
static extern IntPtr formattedLog(IntPtr input, bool isInfo, IntPtr filePath,  uint lineNum);

but since the

DllImport

DllImport

is directly just the dll, I'm pretty sure I have to have

print.dll

print.dll

in the same path as the library right? which brings the question of how do I do that..?
Closest I've gotten is managing to package

print.dll

print.dll

in there but not in the right path causing an exception when you try to print something. Currently what I have so far is as so

  <!--rust dll-->
  <ItemGroup>
    <None Update="bin\Release\net7.0\print.dll" Pack="true" PackagePath="runtimes/win/lib/net7.0">
      <files>
        <file src="bin\Release\net7.0\print.dll" target="runtimes\win\lib\net7.0\print.dll" />
      </files>
    </None>
  </ItemGroup>

  <!--rust dll-->
  <ItemGroup>
    <None Update="bin\Release\net7.0\print.dll" Pack="true" PackagePath="runtimes/win/lib/net7.0">
      <files>
        <file src="bin\Release\net7.0\print.dll" target="runtimes\win\lib\net7.0\print.dll" />
      </files>
    </None>
  </ItemGroup>

which for some reason doesn't even pack

print.dll

print.dll

into the package. Any help would be appreciated!

wasabi•11/12/23, 6:42 PM

Well, there's a lot of weird stuff in your example MSBuild code. Like, what is the nested <files> thing supposed to even be? For .NET Core projects, all you need to do is get it packed into the right path. Which would be runtimes/{rid}/native

Wwasabi Well, there's a lot of weird stuff in your example MSBuild code. Like, what is t...

Logan M.OP•11/12/23, 6:46 PM

If I had it somewhere else it gave me a build error, so I just eventually shoved into .

wasabi•11/12/23, 6:46 PM

Why would you need it anywhere at all?

Logan M.OP•11/12/23, 6:46 PM

Isn't entire purpose this..?

wasabi•11/12/23, 6:47 PM

No.

wasabi•11/12/23, 6:47 PM

There is no such element in MSBuild.

Logan M.OP•11/12/23, 6:47 PM

wait what

wasabi•11/12/23, 6:47 PM

PackagePath is a MSBuild metadata property. So that's correct.

Logan M.OP•11/12/23, 6:48 PM

Im confused though if thats the case wouldnt msbuild have given me an error of somekind about that?

wasabi•11/12/23, 6:48 PM

No, because is interpreted as a metadata property named 'files' set on the items in the itemgroup. Which has no effect, because nothing cares about it.

Logan M.OP•11/12/23, 6:49 PM

but with packagePath though? is there a reason why that fails to package the dll?

wasabi•11/12/23, 6:50 PM

Is there an item in the None ItemGroup which you are updating?

wasabi•11/12/23, 6:50 PM

If not, then the line has no effect either.

Logan M.OP•11/12/23, 6:50 PM

No there shouldnt be.. but wouldn't still have worked here with the paths provided?

Logan M.OP•11/12/23, 6:50 PM

wasabi•11/12/23, 6:51 PM

Update means to update an existing item in the ItemsGroup.

wasabi•11/12/23, 6:51 PM

But if there is no such item in the Itemgroup.... there is nothing to Update.

Logan M.OP•11/12/23, 6:51 PM

wasabi•11/12/23, 6:51 PM

Chances are you want Include.

wasabi•11/12/23, 6:52 PM

But, you also should not package items from the bin directory outside of Targets.

Logan M.OP•11/12/23, 6:52 PM

why shouldn't I exactly?

Logan M.OP•11/12/23, 6:52 PM

its the dll file that matters here right?

wasabi•11/12/23, 6:52 PM

You'll get incorrect metadata reads.

Logan M.OP•11/12/23, 6:52 PM

Logan M.OP•11/12/23, 6:53 PM

in that case what should I do here then?

wasabi•11/12/23, 6:53 PM

Properties and Items outside of Targets get processed when the project loads. At which time bin/ is unlikely to exist.

wasabi•11/12/23, 6:53 PM

Thus, the file won't exist at the time of loading, and thus the item in the None ItemGroup will have no timestamp metadata.

wasabi•11/12/23, 6:53 PM

And incremental builds will be wonky.

wasabi•11/12/23, 6:54 PM

Assuming the file is produced externally, put it somewhere else.

Logan M.OP•11/12/23, 6:54 PM

so I imagine just keep it in strc/rust/target/

wasabi•11/12/23, 6:54 PM

Then `<None Include="..that filewhereever" PackagePath="etc" Pack="true" />

Logan M.OP•11/12/23, 6:54 PM

instead of shoving it in bin on build

wasabi•11/12/23, 6:54 PM

Yes.

Logan M.OP•11/12/23, 6:55 PM

alr i'll try that

wasabi•11/12/23, 6:55 PM

if you want it to be present in bin/ during build of the project, you let the build itself copy it to bin/

wasabi•11/12/23, 6:55 PM

By setting

Logan M.OP•11/12/23, 6:56 PM

would that be in ?

wasabi•11/12/23, 6:56 PM

Yup.

wasabi•11/12/23, 6:56 PM

So when you execute the or target, the copy in bin/ gets deleted. And then copies it back.

wasabi•11/12/23, 6:56 PM

And a second run of compares timestamps, and only copies if out of date.

wasabi•11/12/23, 6:57 PM

should probably be set to

Logan M.OP•11/12/23, 6:57 PM

ok, thanks

Logan M.OP•11/12/23, 6:58 PM

so kinda like so?

Logan M.OP•11/12/23, 7:01 PM

alr yeah that worked thx

Logan M.OP•11/12/23, 7:01 PM