nuget package is compiled as debug about svelto.ecs HOT 18 CLOSED

I guess you could build for both configurations and include both in a custom nuspec file lib\netstandard2.0\Debug\Svelto.ECS.dll and lib\netstandard2.0\Release\Svelto.ECS.dll, using a .target file to automatically reference the correct dll with hint path (paths are probably wrong)

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Reference Include="Svelto.ECS">
      <HintPath>..\packages\Svelto.ECS.1.0.0\lib\netstandard2.0\$(Configuration)\Svelto.ECS.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

Or create 2 packages, Svelto.ECS and Svelto.ECS.Debug, users can reference the package they need using their project configuration

    <PackageReference Include="Svelto.ECS" Version="3.1.3" Condition="'$(Configuration)'=='Release'" />
    <PackageReference Include="Svelto.ECS.Debug" Version="3.1.3" Condition="'$(Configuration)'=='Debug'" />

I don't know if there is a standard way to handle this, just my random thoughts.

I will directly build in release on my environment then instead of using the nuget package for now. I will link my benchmark once done (it's a really simple case with system/engine processing entities with 1, 2 or 3 components), I am using your MiniExample Net Vanilla as a base setup but I wouldn't be against you taking a look if I am using your library correctly and making a fair comparison :)

from svelto.ecs.

@Ujinjinjin we are following a similar solution, aren't we?

Yes, we will use one those solutions

from svelto.ecs.

I guess you could build for both configurations and include both in a custom nuspec file lib\netstandard2.0\Debug\Svelto.ECS.dll and lib\netstandard2.0\Release\Svelto.ECS.dll, using a .target file to automatically reference the correct dll with hint path (paths are probably wrong)

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Reference Include="Svelto.ECS">
      <HintPath>..\packages\Svelto.ECS.1.0.0\lib\netstandard2.0\$(Configuration)\Svelto.ECS.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

Or create 2 packages, Svelto.ECS and Svelto.ECS.Debug, users can reference the package they need using their project configuration

    <PackageReference Include="Svelto.ECS" Version="3.1.3" Condition="'$(Configuration)'=='Release'" />
    <PackageReference Include="Svelto.ECS.Debug" Version="3.1.3" Condition="'$(Configuration)'=='Debug'" />

I don't know if there is a standard way to handle this, just my random thoughts.

I will directly build in release on my environment then instead of using the nuget package for now. I will link my benchmark once done (it's a really simple case with system/engine processing entities with 1, 2 or 3 components), I am using your MiniExample Net Vanilla as a base setup but I wouldn't be against you taking a look if I am using your library correctly and making a fair comparison :)

Thanks for the hint, I will try to include in a nuget both versions of DLLs, and if it's not too troublesome, I will upgrade pipeline, but I will only be able to do it next week

from svelto.ecs.

@Doraku if you are on discord, why don't you join this ECS related server. A lot of ECS framework devs in there: https://discord.gg/UYWMTPCaQG

from svelto.ecs.

Thanks a lot for you assistance. Tried it with dummy project - seems to work fine. Now I'm going to apply it to the Svelto packages

from svelto.ecs.

thank you both!

from svelto.ecs.

Thanks a lot for this

from svelto.ecs.

we are working on a solution for this as we need to distribute both debug and release dll, meanwhile, the best thing for you to do is to use the code directly @Doraku . I will need to work again on Svelto.ECS benchmarks myself, so maybe I can reuse something you do.

from svelto.ecs.

@Ujinjinjin we are following a similar solution, aren't we?

from svelto.ecs.

In case you are interested in my benchmark results (implementations found here).
Pretty impressive (much much better than with the Debug package haha), I guess it is kinda unfair to my framework because of your ExclusiveGroup :p only my component direct access in the SingleComponentEntityEnumeration (DefaultEcs_ComponentSystem) is really equivalent to what you do behind the scene.

from svelto.ecs.

In case you are interested in my benchmark results (implementations found here).
Pretty impressive (much much better than with the Debug package haha), I guess it is kinda unfair to my framework because of your ExclusiveGroup :p only my component direct access in the SingleComponentEntityEnumeration (DefaultEcs_ComponentSystem) is really equivalent to what you do behind the scene.

Oh wow I didn't realise you made an ecs framework too, good job in studying all the other implementations too. I noticed your github project has a used by section. How did you enable it?

from svelto.ecs.

I noticed your github project has a used by section. How did you enable it?

I didn't do anything, my guess is that github automatically checks csproj of public repos and matchs the PackageReference it finds inside. Microsoft probably knows that a package comes from a specific repo thanks to the meta data on nuget.org. I am not sure it will pick up the dependencies of a Unity project though.

Thanks for the hint, I will try to include in a nuget both versions of DLLs, and if it's not too troublesome, I will upgrade pipeline, but I will only be able to do it next week

Np, if you go this road the only "limitation" I see is if someone uses non standard (Debug/Release) configuration names. Maybe use $(Configuration)'=='Debug' and $(Configuration)'!='Debug' (or even a specific property <SveltoDebug>true</SveltoDebug> that the user need to declare in his csproj) so you fallback to the Release dll by default.

from svelto.ecs.

@Doraku I checked the implementations, again I am impressed that you went through the pain to understand all the various setup but I have a question, are your systems running in multithreading? I see parallel runner so I am wondering.

from svelto.ecs.

Yes I made my systems so they can be run in parallel when it is safe to do so through the IParallelRunner interface (my guess is that if I ever try to include my framework in Unity I would need a specific implementation using jobs instead of my current one using tasks so I wanted it easily extensible), that's why the benchmarks of my framework has a "System" (single thread) and "MultiSystem" (multithread) variant. I think Svelto support it too with Svelto.Tasks or Unity jobs? But I didn't go as far as putting them in my benchmark for now, at least I can compare single thread performance.

from svelto.ecs.

thanks for the explanation and it's fine. Svelto.ECS has been designed to leave completely the ticking responsibility to the user. Svelto.Tasks is just an option, but since I have never completed the 2.0 version is not really a viable one. I will need to implement a dependency tracking system one day.

from svelto.ecs.

I guess you could build for both configurations and include both in a custom nuspec file lib\netstandard2.0\Debug\Svelto.ECS.dll and lib\netstandard2.0\Release\Svelto.ECS.dll, using a .target file to automatically reference the correct dll with hint path (paths are probably wrong)

Hey, @Doraku, I finally found some time to spare on this issue. May I ask you to help me with it? I thought I understood how to solve it, but apparently I didn't (not familiar with that kind of magic), so I have some questions:

• where should I put .targets file? Should I place it in the root folder of package source code or in the bin folder after I build is finished?
• what should I do next? Just pack nuget package and publish it?

I would really appreciate if you'd explained this process to me step by step (assuming you know how to)

from svelto.ecs.

Sure, I have only use target file to add post compile process through a nuget package but it should work the same for references.
Basically, you want your nuget package structure to look like this:

• lib
  • Debug
    • netstandard2.0
      • Svelto.ECS.dll
  • Release
    • netstandard2.0
      • Svelto.ECS.dll
• build
  • Svelto.ECS.targets

You can chose the organization you want for Debug/Release folders but the targets file NEED to be inside the build folder, that way it will be picked up automatically by project referencing your package. Knowing that you can then declare references to the correct dll in the targets file like so:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Reference Include="Svelto.ECS">
      <HintPath>$(MSBuildThisFileDirectory)../lib/$(Configuration)/netstandard2.0/Svelto.ECS.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

$(MSBuildThisFileDirectory) is a special property which give you the targets file location, so all you need to do is point to the dll file from there. Here I am using directly the $(Configuration) property to point to the correct dll base on the configuration of the project (Debug/Release) but in case users are not using standard configurations name maybe if would be better to do something like this instead:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Reference Include="Svelto.ECS">
      <HintPath Condition="'$(Optimize)'!='false'">$(MSBuildThisFileDirectory)../lib/Release/netstandard2.0/Svelto.ECS.dll</HintPath>
      <HintPath Condition="'$(Optimize)'=='false'">$(MSBuildThisFileDirectory)../lib/Debug/netstandard2.0/Svelto.ECS.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

using Condition on the Optimize property of the project to reference the correct dll.

Note that you would probably need to build manually the project for Debug and Release and then pack everything.
Also I haven't tested any of this but from my understanding of msbuild it should work, I hope I am not putting you on the wrong track :D

from svelto.ecs.

#63 done

from svelto.ecs.