Fire IDE does not honor disabling Copy Local on references

Elements Fire
1

IDE: Fire
Version: 8.3.93.1987
Platform: .NET
Language: Swift
Description: Disabling “Copy Local” still copies references to build directory.

I’m seeing odd behavior with “Copy Local” in the Fire IDE with .NET references. It looks as if non-system level references do not honor “Copy Local” correctly. To reproduce:

  1. Create a new Class Library project with Platform set to .NET and Language set to Swift.
  2. Expand References section in the Project Tree and notice that Echoes has “Copy Local” set.
  3. Inspect the .elements file and notice XML similar to:
...
<Reference Include="Echoes">
  <Private>True</Private>
</Reference>
...
  1. Build the project and notice that Echoes.dll is correctly in the appropriate Debug or Release directory.
  2. In the References section of the Project Tree, right click Echoes and select “Copy Local” so it is unchecked in the context menu.
  3. Inspect the .elements file and notice XML similar to:
...
<Reference Include="Echoes"/>
...
  1. Clean the project.
  2. Build the project and notice that Echoes.dll is still added to the Debug or Release directory.

As noted in the steps above, it looks as though a Reference can optionally include a Private tag explicitly set to True when Copy Local is checked in the context menu. When Copy Local is not set there is no Private tag for the reference and I’m assuming the intention is the default is False. But for non-system level references, I have to manually update the .elements file with a Private tag set to False to get the expected behavior. I see the same result when adding my own references to the project.

Am I missing something?

2

I can reproduce in 8.4.96.2033 (beta) as well.

3

We’ll check, but iirc Private is just a “hint”, andthere’s a additional smarts in the build chain that will determine if a reference ends up being copy-local. depending on where it comes from. eg Echoes.dll must be copied, or your app won’t run, after all.

4

Thanks for the reply Marc!

We’ll check, but iirc Private is just a “hint”, andthere’s a additional smarts in the build chain that will determine if a reference ends up being copy-local.

:thinking:

It seems to behave as more than a hint. In simple tests where I set <Private>False</Private> directly in the .elements file, the .dll is not copied over. Even if there are imports in my source for classes in the .dll.

This works how I expect, but it feels weird to have to manually update the .elements file. Especially since it seems to occasionally confuse the IDE into thinking it can’t find references. While building is fine, I sometimes have to close the project and reopen so the UI correctly reflects it resolved the references.

depending on where it comes from. eg Echoes.dll must be copied, or your app won’t run, after all.

I mentioned Echoes.dll specifically since it was simple to demonstrate the behavior with the project template. Unfortunately, I see the same behavior when adding references to my own .dlls too.

And that reasoning makes sense, except I don’t want my class library’s build directory to have those dependencies copied. I will make sure those dependencies are satisfied when deployed and I want to inform the build process of that. I thought “Copy Local” was the way to do that.

But maybe I made the wrong association between the UI and .elements file or am trying to use the wrong functionality for this?