Several errors while trying to compile

[Krakean]

https://pastebin.com/ZVRKYBwA Hello. Any ideas why I receive these errors while trying to compile latest master using VS2017.9?

P.S. Not related question, but is this - https://i.imgur.com/rlsbkBq.png - really should be for all configurations? Seems like Release cannot be compiled without 'PROFILE' define too.

[RossNordby]

Those errors appear related to a bit of an odd shortcut I took that only works on .NET Standard. Certain types are dummies in .NET Standard, so the initialization requirements are loosened because as far as the compiler is concerned their contents can't change program behavior. Of course, since the content of the memory is being interpreted for intrinsics, that isn't actually the case- and when compiling the library for .NET Core instead of .NET Standard, the compiler notices because of the different implementation.

Are you seeing the errors while the BepuPhysics and BepuUtilities projects are targeting .NET Standard 2.0?

(This isn't intended as a permanent situation. It's obviously fragile and there have been two nasty bugs caused by doing it (so far), and there's a good chance that I'll need to move fully to .NET Core eventually for intrinsics related reasons. I've just been delaying the work involved.)

P.S. Not related question, but is this - https://i.imgur.com/rlsbkBq.png - really should be for all configurations? Seems like Release cannot be compiled without 'PROFILE' define too.

I went ahead and revamped the profiler a little bit (64f5b6a9d8e5f3240fa73169a4eb3b0b4ed7d2a6); there's now a ReleaseStripNoProfiling and the API doesn't change based on the compilation symbol (the implementation is just disabled).

[Krakean]

Are you seeing the errors while the BepuPhysics and BepuUtilities projects are targeting .NET Standard 2.0?

I suppose yes, but I trying to compile using .net core (2.2, specifically) as netcoreapp2.2 application, not really care about .net standard because well .net core is future in my opinion, its multiplatform, most actual, and updated frequently, so not much reasons, in my case, targeting .net standard for mono/.net framework compatibility, especially when .net core 3.0 will come and will allow to bundle runtime into application so you can do not depend on .net installed on user computer.

I'll need to move fully to .NET Core eventually for intrinsics related reasons

Yezzz, please :) And, may be to clean some code. Like WideRayTester.cs. Seems like its not used anywhere...

I went ahead and revamped the profiler a little bit (64f5b6a); there's now a ReleaseStripNoProfiling and the API doesn't change based on the compilation symbol (the implementation is just disabled).

Nice. Thanks for your work on BepuV2, can't wait for final 1.0 release :) P.S. If you will have some free time, please update roadmap :)

[RossNordby]

I suppose yes, but I trying to compile using .net core (2.2, specifically) as netcoreapp2.2 application, not really care about .net standard because well .net core is future in my opinion, its multiplatform, most actual, and updated frequently, so not much reasons, in my case, targeting .net standard for mono/.net framework compatibility

So just to clarify, you only observe the errors with the library targeting netcoreapp, not netstandard2.0, right? If so, I'm not too worried about it for now. Using a .NET Standard library in a .NET Core application (like the Demos application) still provides all the benefits of .NET Core; the only difference is the API exposed to me within the library itself. Users don't lose any performance or deployment features. (Hence the reason why targeting .NET Core once platform specific intrinsics mature makes sense- that API simply isn't available from .NET Standard.)

And, may be to clean some code. Like WideRayTester.cs. Seems like its not used anywhere...

That's partially for certain advanced external use cases, and partially for future internal uses (batched ray tracing isn't quite where I want it to be on every platform coughcoughryzen). Not super important, but not worth deleting yet.

P.S. If you will have some free time, please update roadmap :)

Looks current as is.

[Krakean]

So just to clarify, you only observe the errors with the library targeting netcoreapp, not netstandard2.0, right?

Yes

[Krakean]

@RossNordby have you able to reproduce these errors?

[RossNordby]

Yes- it's a known limitation. The library is currently only designed to target .NET Standard and won't compile when setting the library's target to .NET Core. I'll revisit this later when I start integrating platform intrinsics (which are not available in .NET Standard).

(But just to reiterate for anyone skimming through this thread- you can still use it from a .NET Core application just fine with full features and performance. Targeting .NET Standard within the library only affects which APIs are available within the library and does not limit applications using the library.)

[Krakean]

@RossNordby

I'll revisit this later when I start integrating platform intrinsics (which are not available in .NET Standard).

Can you please tell me approximate estimate when you planning to do this?

Targeting .NET Standard

Thing is such approach not really possible within my structure, because I have one common 3rdparty dll which contains all dependencies used by mine 3d engine and it looks like this: https://i.imgur.com/8qWfkcD.png And within these folders - only source files, without these project's csproj files, because they all managed by one Nuage.3rdParty.csproj file, and there specified only netcoreapp as targetframework

[RossNordby]

Can you please tell me approximate estimate when you planning to do this?

No good estimate; I'd put a lower bound at NET Core 3.0 stable release date + 4 months, but it could easily be longer depending on what I happen to be working on. It also depends on the ecosystem- if it looks like maintaining a .NET Standard version is valuable for certain use cases (like, say, Unity), it could change my plans a bit.

85% chance that I'll do it within 3 years. Most of the remaining 15% is 'something happened that made doing it irrelevant'.

I may also fix these issues before I deal with platform intrinsics, but even that has a lower bound of C# 8.0 stable release + 2 months.

Thing is such approach not really possible within my structure

Sorry, that use case just isn't supported right now.

[Krakean]

I may also fix these issues before I deal with platform intrinsics,

You mean ".NET Platform Dependent Intrinsics" that are available in release of .NET Core 3.0 preview 2 (https://github.com/dotnet/core/blob/master/release-notes/3.0/preview/3.0.0-preview2.md)?

Sorry, that use case just isn't supported right now.

Sad to hear, seems like have to stay with Bepu v1 then...

[RossNordby]

You mean ".NET Platform Dependent Intrinsics" that are available in release of .NET Core 3.0 preview 2

Yes. As v2 moves out of early development, I don't want it to depend upon prerelease libraries and runtimes.

Sad to hear, seems like have to stay with Bepu v1 then...

While I still can't promise any change in the timeline, could you elaborate on why a separate .NET Standard project is not workable for you?

[Krakean]

Yes. As v2 moves out of early development, I don't want it to depend upon prerelease libraries and runtimes.

Understand. But since v2 still in beta, and MS plan to release .net core 3.0 in spring timeframe, it doesn't seems too bad to me if you will start evaluate dotnet 3.0 within v2 a bit earlier. At least, in separate branch may be? :) Once 3.0 released, v2 will be ready for it in time :)

While I still can't promise any change in the timeline, could you elaborate on why a separate .NET Standard project is not workable for you?

May be the same reason why I use BEPU instead of PhysX or Bullet at all -- it allows me do not have separate dlls in my project, keeping my project and its structure clean of external dependencies, being outstanding physics engine (in C# ecosystem) and to my surpise very undervalued project. So, in result, I will feel myself very uncomfortable when I have one dependencies dll where all deps (~15) are placed, and v2 as separate dependency dll :)

[RossNordby]

Once 3.0 released, v2 will be ready for it in time :)

If I had a hyperbolic time chamber, perhaps... :)

I will feel myself very uncomfortable when I have one dependencies dll where all deps (~15) are placed, and v2 as separate dependency dll

If deployment is the primary concern, they're working toward single-file publishing- either through CoreRT in the long run, or something like this in the shorter term: https://github.com/dotnet/designs/pull/52

[Krakean]

If deployment is the primary concern, they're working toward single-file publishing- either through CoreRT in the long run, or something like this in the shorter term: dotnet/designs#52

I'm waiting this feature very much! But still, it doesn't decline requirements to keep clean internal project structure :)

[Krakean]

@RossNordby Hello Ross :) Curious, may be you can revisit this issue since .NET Core 3.0 Preview 4 is out? At least, on experimental branch. So I can use experimental branch until you merge it into master when netcore 3.0 final will be released

[RossNordby]

Sorry, it's still going to be a while (at minimum a few months, likely more) before I can fiddle with this. Other things take priority for now.

[RossNordby]

Recent commits on master have moved the library to .NET 5.