I have some files in the project (so they’re in the repo) that need to be copied to the output directory.
I’d like to be able to use subdirectories, but the files are all written to the same directory as the compiled file.
Whatever I enter under “Copy Destination” doesn’t seem to have any effect.
(VS 2022, 17.13.6 - Elements 12.0.0.2981) (Doesn’t work as expected in Water either.)
Do you have a small test case that shows how you have this set up and expect work?
In general the Elements build (EBuild) acts on files based on their build action and file name; their file location relative to the project has no relevance to what is or isn’t done to the files, ie if you have
<Compile Include="Foo.pas"/>
<Compile Include="x/Bar.pas"/>
<Content Include="Foo.txt"/>
<Content Include="x/Bar.txt"/>
Foo and Bar will be acted upon in the same way, no matter their relative or absolute path; Bar.txt would not be copies into a subfolder called “x”, just because that’s where art happens to originale.
That is the expected behavior, currently.
“Copy Destination” looks to maybe be a VS thing, but its not a value that EBuild (currently) handles or honors in any way.
Application1.7z (20.9 KB)
Hi Marc,
i attached the testcase from the screenshot above.
Expected outcome is: Textfile1.txt is copied to $OutputDir and Textfile2.txt should be copied to $OutputDir\Sub\
Or is there another way to handle files (like images, html-documents…) that should reside in the project/repo, which should later end up in the output directory?
Tried to copy the files with a post-build-script, but i couldn’t get this to work either. (Exception for unknown Platform attribute for example, had no time to investigate further.)
Okay, that may be the Internet tin but it’;s now his this works 
Tis might be the best option. What exactly did not work here?
It works this way in pure Microsoft-Solutions.
Post-Build-Stuff:
If there is no other chance, i have to get this running. For my first try, i wrote this “script” into the textbox in the “Post-Build Event Command Line”-dialog.
echo $(ConfigurationName) >> text.txt
This added the following to the elements-file:
<PropertyGroup>
<PostBuild Condition="'$(Platform)' == 'Echoes'" Platform="Echoes">echo $(ConfigurationName) >> text.txt</PostBuild>
</PropertyGroup>
Building the solution failes…
1>------ Build started: Project: Application2, Configuration: Debug ------
1>Unhandled Exception:The attribute "Platform" in element <PostBuild> is unrecognized. D:\Entwicklung\PoC\Application2\Application2.elements
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
If i remove the “Platform” attribute, the build succeeds and the script seem to be executed, but the Macros doesn’t seem to work.
|1>|| -> Task RemObjects.EBuild.Elements.ElementsProjectPostBuildTask started for Application2.|
|1>|| |
|1>|| D:\Entwicklung\PoC\Application2>echo 1>>text.txt |
|1>|| <- Task RemObjects.EBuild.Elements.ElementsProjectPostBuildTask finished for Application2, took 0,0356s (0.035s).|
Also, the Post-build Event dialog (invoked via the button at the Project-properties isn’t populated with the script content any longer. And i am not sure about the drop-down-list in this dialog…
(The drop-down seems to be correctly populated if i readd the Platform attribute - the whole dialog isn’t working properly if the attribute is removed. The options seem to have no effect, changes are not reflected in the elements file…)
Conclusion: If the “Platform Attribute” is included, the dialog seems to work, but the build doesn’t. If you delete it, it’s the other way around - but then the macros don’t work.
Sorry for the messy post, i edited it along testing.
EBuild is not MSBuild. It’s currently working the way we intend it to work.
Hmm, tis error seems to be coming from the MSBuild wrapper, when building in VS :(. Its can be picky with syntax <SBuild dense know, and the Platform= is EBuild specific… It should work without the platform filter, assuming you did not need your project to build n Wndows and Mac, that shuiod be fine.
$(ConfigurationName) is not a kn own variable. yo probably want $(Configuration)?
Oops. that seems to be a VS bug. Can you send me the project as-is that shows this, so I can log a ticket for the VS team…
thanx,
marc
But you should consider that… Why supporting “CopyFiles” when the folder-information is omitted? Haven’t tried out what happens when two files have the same name… like index.html or whatever. (Meanwhile i tried out what happens with two files with same name - the first file will be overwritten by the second one.)
As for now, i didn’t take a look at “ebuilds” - because there was no need for me to do so. I was not aware, what is done by MSBuild and what not.
I picked the macro from the dialog for testing… Maybe you create a ticket to check that, too.
Any fresh solution will do it. After creating a project → Properties → Post-Build Event (Pre-build not tested) - the dropdown is populated as seen in my previous screenshot. Always.
After entering a script, and entering the dialog again, the dropdown is populated correctly.
After deleting it, the dropdown is shredded again.
After opening a solution with a script in it, the dialog is also empty.
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
Thats the one that matters. I don’t know why VS shows the other one, it probably just sows all variables MSBuild knows…
Okay, I’ll with this info.
Logged as bugs://E27166.
bugs://E27166 was closed as fixed.
I was using Elements 12.0.0.2929 and Visual Studio 2022 (17.14.4) and my PostBuildEvent was not working. I was getting an Unhandled Exception.
I’ve found and followed this thread and updated to Elements 12.0.0.2995 to get the fix for E27166. My PostBuild script now runs, but none of the Macro Variables are defined. Here is my script defined in the project file:
<PropertyGroup>
<PostBuild>echo "Hello World"
echo "TargetDir = $(TargetDir)"
echo "ProjectDir = $(ProjectDir)"
md "$(TargetDir)x64"
md "$(TargetDir)x86"
copy "$(ProjectDir)..\..\Common\SubRepositories\commondlls\EmguCV\x64\*.dll" "$(TargetDir)x64"
copy "$(ProjectDir)..\..\Common\SubRepositories\commondlls\EmguCV\x86\*.dll" "$(TargetDir)x86"
copy "$(ProjectDir)..\..\Common\Used Dlls\Ximea\XimeaWrapper\X86\*.*" "$(TargetDir)x86"
copy "$(ProjectDir)..\..\Common\Used Dlls\Ximea\XimeaWrapper\X64\*.*" "$(TargetDir)x64"
</PostBuild>
</PropertyGroup>
Here is the output from the build:
31> -> Task RemObjects.EBuild.Elements.ElementsProjectPostBuildTask started for xxxxxxxxxxxx.
---------
31>D: C:\WINDOWS\system32\cmd.exe /c C:\Users\flagattuta\AppData\Local\RemObjects Software\EBuild\Obj\9E5ED5997C43D19C246813B034AD7E9715AAD457\Postbuild.cmd
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>echo Hello World
31> Hello World
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>echo TargetDir =
31> TargetDir =
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>echo ProjectDir =
31> ProjectDir =
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>md x64
31> A subdirectory or file x64 already exists.
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>md x86
31> A subdirectory or file x86 already exists.
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>copy ..\..\Common\SubRepositories\commondlls\EmguCV\x64\*.dll x64
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\concrt140.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\cvextern.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\libiomp5md.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\libmmd.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\msvcp140.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\opencv_ffmpeg320_64.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\svml_dispmd.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\tbb.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x64\vcruntime140.dll
31> 9 file(s) copied.
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>copy ..\..\Common\SubRepositories\commondlls\EmguCV\x86\*.dll x86
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\concrt140.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\cvextern.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\libiomp5md.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\libmmd.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\msvcp140.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\opencv_ffmpeg320.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\svml_dispmd.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\tbb.dll
31> ..\..\Common\SubRepositories\commondlls\EmguCV\x86\vcruntime140.dll
31> 9 file(s) copied.
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>copy ..\..\Common\Used Dlls\Ximea\XimeaWrapper\X86\*.* x86
31> The system cannot find the path specified.
31>
31> C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000>copy ..\..\Common\Used Dlls\Ximea\XimeaWrapper\X64\*.* x64
31> ..\..\Common\Used Dlls\Ximea\XimeaWrapper\X64\XimeaWrapperX64.dll
31> ..\..\Common\Used Dlls\Ximea\XimeaWrapper\X64\XimeaWrapperX64.pdb
31> 2 file(s) copied.
31> <- Task RemObjects.EBuild.Elements.ElementsProjectPostBuildTask finished for xxxxxxx, took 2.1686s (2.168s).
As you can see, the Macro Variables in the script have no values. Some of the files get copied, but they get copied to the wrong place because $(TargetDir) and $(ProjectDir) are blank.
In the Build Output I can see that they have values. For example, TargetDir is defined as:
31> TargetDir = C:\GSDSoftware\thunderbolt-software-dev\InstrumentGUI\AIX1000\bin\Debug\
Why does the PostBuild script not see this value?
Any help is greatly appreciated. This is driving me crazy and causing delays in my project. I need a fix ASAP!
ProjectDir and TargetDir are not EBuild variables; it seems they are specific to the MSBuild host (which is only used in VS). Only EBuild variables are available for pre- and post-build scripts.
I’ll add a “ProjectFolder” variable (“Folder” is more in sync with the rest of EBuilds variable naming) for vNext. for TargetDir, you can use “OutputPath”, which already exists. (which,i realize, should be called OutputFolder for consistency, but its currently not
Thanks for the update. I will be on the lookout for the vNext – any idea when this will be released?
-Frank
We’ll have a new build this Friday. Unfortunately we had to sklip last weeks, as i had a lot of balls in their with large changes that didnt come together in time for a build – but i’ll be worth the wait.