"Copy Always" files in sub folders not copying to equivalent \bin sub folder

Seems any version of Elements since 10.0.0.2305 doesn’t copy “Copy Always” files that are in sub folders of the project to the corresponding sub folder in the build destination folder, but just copies the files straight to the destination folder.

example

    project.oxygene
      x86 (folder)
        somefile.dll
      x64 (folder)
        somefile.dll
      
when built using version 2305
dest (folder)
  project.dll
  x86 (folder)
    somefile.dll
  x64 (folder)
    somefile.dll

when built using post version 2305
dest (folder)
  project.dll
  somefile.dll

So as you see the somefile.dll is now just one of the original ones and not in the appropriate sub folder

Alex

I’ll have a look. Do you have a test case handy?

Thanks, logged as bugs://82923

That said, I’m not even sure if id consider this desirable in every case. Usually project structure does not really inform output structure.

Maybe not, but that’s how it’s always worked, C# projects behave the same, so whatever you may think is right, the newer versions break existing projects.
I don’t quite understand your comment about projects not informing output structure. If an included file in a project has been set as “Copy if newer” or “Copy always” and it’s within a sub folder of the project, that usually signifies that that is where you want the file to appear in the output

Alex

Well, take for example my project for Water. I have images and source files in a bunch of folders. those folders represent how I think of and structure my project — ie grouping related files — and not where things go in the final executable. I’m not sure I woulds think if “copy local” files much differently.

I’m not quite sure where you expect me to go with this, all I’m saying is that a product that I’ve been paying for and been using for many years has now changed behaviour, meaning it no longer works for us as it has up to now. The result of which is that I am not able to use it’s latest version. With such a huge breaking change, first you should of at least given some sort of indication of it in the release notes. To be honest, I would of thought you could of added a setting or project option to opt into new behaviour.

Well, I logged an issue to investigate what to best do here. I just mentioned as a heads-up that, right now, the current behavior seems more desirable, more “correct” to me that the old one.

It might be helpful if you could give me a concrete use case/scenario for what you would want to do where the old behavior or copying files with the same folder structure as they have in your project would be useful, as that might help us find a good solution that covers both scenarios.

Possible solutions might be a flag on the individual item, or even an optional target folder metadata setting on there individual item (iirc we already have a “DestinationFolder” setting that is currently only honored for Mac .app Bundle creation (I just checked), but it might make sense to let the same value also work for “CopyToOutputDirectory” items, as well…

Guess I must be the only user that seems to of been effected by this change in behavior. Anyway the situation where it’s a problem is I have a project that uses a nuget package, that package places 2 native dll’s with the same name within the project under sub folders x86 and x64, now when the project is compiled the dest folder only contains one of them and no sub folders. This means that the program will fail to run when it looks for the appropriate dll.

Another thing that also seems to of changed is propagating dll’s from included projects

example
project1 references project2 and project 3 references project1
When you compile project3, the dest folder is missing project2.dll

I know that by making changes to my projects (ie reference project2 from project3) that would fix it, the point is that things had changed that completely break my builds but compile without errors. Would of been nice to of been warned of these breaking changes than me spending ages trying to figure out what was going on

Note that we have quite a lot of oxygene projects that would now be broken without intervention which would cost us a lot of time and money to fix

Can I get a concrete test case for this? a NuGet package should not be placing any files into the project folder hierarchy itself, so this likely is unrelated to “CopyToOutputDirectory”.

Hmm, this too should work, of both are project references, and set to Copy Local (ie “Private”). a test case would be appreciated.

If the CopyLocal references do not work, that’s a bug, not an intended change.

If a nuget package has anything under the “content” folder, which itself can have sub folders, it’s contents are just added to the project, maintaining the folder hierarchy

OK have done some more testing and seems, that the dll propagation does actually work when referencing projects, what has changed, is the logic of when to set “Copy Local” to true or false when it’s not specified in the project file, older versions of Oxygene seem to automatically set it to true for dll’s that, by the looks of it, aren’t part of the framework, whereas the newer versions now leave it as false.

Back to my original issue of the “Copy always” files in project sub folders not keeping the folder structure, which by the way works for MS C# projects, how should we proceed?

Right, a NuGet package can have content, and that should be copied to the output. If it is not (or wrongly), that is a bug. A gesticulates case would be appreciated.

MSBuild had slightly more obscure rules for when to do Copy Local, yes, basically treating the flag more as a suggestion. EBuild will honor it properly, always Copy Local when its set, and never when it’s not set. So this behavior is “as designed”.

As I said above, a test case would be appreciated, and then I’ll look at finding a solution (which might mean making it work as is, or supporting a DestinationFolder setting). Note that this would be separate from there NuGet issue (which I also would appreciate a test case for).

thanx,
marc

Have attached a simple nuget package that has “content”
TestPackage.2.0.0.nupkg.zip (13.8 KB)
note: no need to unzip just remove the .zip from the end of the name

add this package to a C# project and the 2 folders x86 and x64 will be added with content, set the 2 files to “Copy Always” then compile, the dest folder will have to 2 sub folders x86 and x64, now do the same for an oxygene project and the 2 sub folders are not present

Thanx. I’ll have a look and get that fixed ASAP; cannot promise it will make tomorrow’s build though.

Out of curiosity, how are you referencing a local NuGet package in your project? Because right now we don’t actually support that — I’m fixing this now as part of this issue…

It’s very simple, just put the package into a folder on disk and add a new nuget source that points to the folder, then you’ll be able to add it to the project as usual

1 Like

Ah, ok, you actually configured a local repository…

That said, I’m super confused by this whole issue because, as I’m looking into this, i’m seeing that content from NuGet packages was not being handled at all. But after I fixed that, the path already is being preserved correctly.

So whatever you are seeing must be something totally unrelated — which a complete test case might have helped show.

In either case, tomorrow’s build will (a) support NuGetReferences with HintPath to a local .nuget file (which was not supported before) and (b) support copy-locating the content folder from a NuGet package, preserving it’s folder structure:

<NuGetReference Include="TestPackage:*">
  <HintPath>..\..\Downloads\TestPackage.2.0.0.nupkg</HintPath>
</NuGetReference>

Final Output for 'NuGetContent':
  Echoes.dll (/Users/mh/Test Projects/NuGetContent/Bin/Debug/Echoes.dll)
  Echoes.dll.mdb (/Users/mh/Test Projects/NuGetContent/Bin/Debug/Echoes.dll.mdb)
  Echoes.pdb (/Users/mh/Test Projects/NuGetContent/Bin/Debug/Echoes.pdb)
  ElementsLib.dll (/Users/mh/Test Projects/NuGetContent/Bin/Debug/x64/ElementsLib.dll)
  ElementsLib.dll (/Users/mh/Test Projects/NuGetContent/Bin/Debug/x86/ElementsLib.dll)
  NuGetContent.exe (/Users/mh/Test Projects/NuGetContent/Bin/Debug/NuGetContent.exe)
  NuGetContent.exe.mdb (/Users/mh/Test Projects/NuGetContent/Bin/Debug/NuGetContent.exe.mdb)

Ah, by the looks of it, your using a new style project, which I can’t even figure out how to achieve for an Oxygene project, I’m still with old style with the packages.config file and not the < NuGetReference > thing in new style projects

Elements has been using EBuild for all projects for over a year now. What version of Elements are you using? packages.config is a VS thing and is processed before our build runs (but afaik all this does it inject references into the project. @viktoriad might k ow more about this interaction when she’s back from vacation next week.

That said, the NuGetRefererence should work, if added to the project; see https://docs.elementscompiler.com/Projects/References/PackageReferences/ for details.