Hello,
I have a question whether there is a support for Conditional compilation symbols in .elements project files. In our company we use different versions of some parts of our aplications and we would like to be able to write code where (thanks to those symbols) we would be able to program different behavior for different versions in one file.
We use this procedure for C# projects (.csproj files).
Thank you for your help,
David
ifdefs and conditional compilation has been working since the beginning. What specific feature are you missing?
We would want to use this:
<ImportProject="$(SolutionDir)CommonSettings.targets"/>
which is an import statement that is in .csproj files that loads conditional compilation symbols from .targets file. My question is, what is the correct syntax that i write to .elements project file to be able to use this feature.
Elements projects built using EBuild (that’s most of them, except ASP.NET and UWP) currently do not support <Import>, as that’s an MSBuild-specific feature. I’ll look at supporting this in a future update (but only settings and objects would be read from the imported file; it would not support executing actual MSBuild targets/tasks defined within.
Separately, specifically for conditional defines, I’m about to add a new setting, AdditionalConditionalDefines that can be used to add conditional defines from the command line. (While passing --setting:ConditionalDefines=... will of course override those defined in the project, --setting:AdditionalConditionalDefines=... will add to them). This change will be in todays build.
Thanks, logged as bugs://82563
Thank you for response,
the command line option is neat but we really need to be able to use msbuild for this (to just cklik on elements project in Visual Studio and build it from there).
When you mentioned adding support for in the future, would it help us with our problem?
Possibly. Can you send me an example that shows that you’d have inside CommonSettings.targets?
Of course 
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<DefineConstants>$(DefineConstants)TEAF_1201PLUS;TEAF_1301PLUS;TEAF_1401PLUS;TEAF_1401</DefineConstants>
</PropertyGroup>
</Project>
I also wanted to ask whether EBuild supports conditional references?
Specifically I mean this:
<ItemGroup Condition=" '$(TargetFramework)' == 'net462' ">
<Reference Include="System.Web" />
</ItemGroup>ok, cool. in principle this is going to work once I implement the issue above, the only part I cannot make promises about yet is the recursive nesting of the variable. (unrelated, your example there is missing a semicolon, and would probably fail if the existing DefineConstants doesn’t end on ;?)
Not currently, no. I’ll log a feature request.
Thanks, logged as bugs://82575
Hello, id like to ask for more details, why bugs://82563 got closed with status wontfix ? We are building elements projects via msbuild, and Imports with extra targets are perfectly working. Why isnt that possible for importing PropertyGroups definitions ?
https://docs.microsoft.com/cs-cz/visualstudio/msbuild/customize-your-build?view=vs-2019#directorybuildprops-example
It’s just not a direction we want to go in, with EBuild. EBuild does not use Imports, except as a fallback to determine the target platform based on the name of the (previously used) Elements .targets file.
Note that if you are using EBuild hosted in MSBuild (say from VS, or by running msbuild.exe yourself), MSBuild should be handling Imports already with no action from EBuild needed.
Ok, we were aware that this is msbuilds bussiness, but it appeared not working with elements projects and props. Ive checked the original issue again and i found that importing targets and properties both works correctly. I Dont know if we did something else wrong or you fixed it, but now it works. Good Thanks.
Would be possible to make VS syntaxhighlighting affected by DefineConstants from imports ? Maybe that is why we previously marked this as not working, because the syntaxhighlighting isnt affected.
But compilation is just fine.
We are still stuck with UseLegacyPreprocessor true and RemObjects.Elements.Echoes.Legacy.targets
Just asking
Thank you
Probably, I’ll log an issue for the VS team. if you could create a small test case that helps show this issue, that’d be appreciated and would help.
Ah, then you’re to even using the MSBuild-hosted EBuild, you’re using the legacy MSBuild-only build chain, no EBuild involved at all.
Mind if I ask what keeps you on RemObjects.Elements.Echoes.Legacy.targets? I fixed a few issues that kept others on legacy, over the past month or two, so maybe you’re clear to switch now, as well (and if not, I can look at addressing the remaining concerns).
Probably, I’ll log an issue for the VS team. if you could create a small test case that helps show this issue, that’d be appreciated and would help.
Ill make that case asap.
Mind if I ask what keeps you on RemObjects.Elements.Echoes.Legacy.targets?
There is only one remaining issue in my evidence:
Which you cannot reproduce, and I have to try a re-check. So far it happened here on every machine we tried. Its a big problem on TFS automated build pipelines where we cannot turn off parallel builds because it is really killing continuous builds.
Ah, that one. It’s very odd, yeah. Neither me or Carlo could reproduce this; my gut feeling, from the log I saw, is seems me that somehow MSBuild doesn’t detect the dependencies between EBuild project references, and it somehow is building project B that depends on A, before A has finished (or started), IIRC.
Isn that’s the case, that bug should be hidden/worked around if you explicitly set dependencies inside the Solution file (BS has a dialog for that). you’d get sections like this in the .sln:
ProjectSection(ProjectDependencies) = postProject
{F8A2E4F6-C122-4A06-A27B-D77591E674CD} = {F8A2E4F6-C122-4A06-A27B-D77591E674CD}
{4D283143-C13F-478F-A328-485E98D22CF1} = {4D283143-C13F-478F-A328-485E98D22CF1}
EndProjectSection
Does that fix/hide the problem? If not, then the issue seems to be something else. I’ll review the other thread again as well.
the cleaner/simpler a tests you could create where this fails for you (and a corresponding log), the better the chance that I can narrow this down w/o a local repro…