StarcounterVersionCompatibility with multiple SC versions

[joozek78]

I have a library which is (AFAIK) compatible with all versions of Starcounter. It currently fails on 2.4 with the following error:

This project specifies no Starcounter version compatibility. For Starcounter versions 2.4 and above, that is a requirement. By using versions >= 2.x of the Starcounter Visual Studio extension, projects are properly configured from start. If you want to configure the project yourself, set property `StarcounterVersionCompatibility' to '2.4'. Please see https://github.com/Starcounter/Starcounter.VisualStudio/wiki/Version-compatibility if you need further help.

1. What value should I pick for StarcounterVersionCompatibility?
2. wiki/Version-compatibility should be updated to include this case. This article is linked in the error message

[per-samuelsson]

@joozek78

Just to be able to improve it futher: what exact information are you missing from the referenced troubleshooting section?

[per-samuelsson]

The thing with the 2 versions in play here - i.e. 2.3 and 2.4 - is that we kind of decided to make that leap one where we would have our users do some manual things, because we wanted to redesign the hosting model.

For one, the 2.4 runtime expect a different set of referenced assemblies, and also that assemblies are set to be copied local (as opposed to all versions prior to that).

For other projects, I've split them up in branches accordingly. Like Simplified - the "master" branch correspond to 2.3, the "develop" branch to 2.4.

[joozek78]

I see, looks like I have to create separate configurations for those branches

[per-samuelsson]

I see, looks like I have to create separate configurations for those branches

Yeah, sorry for that, it's not ideal. I'm actually spending some time thinking if there could be a way to simplify that switch, but atm, 2.3 and 2.4 will need some hands on migration of project file (code should be compatible though). I'll let you know if I get a chance to actually improve it.

[joozek78]

For one, the 2.4 runtime expect a different set of referenced assemblies, and also that assemblies are set to be copied local (as opposed to all versions prior to that).

@per-samuelsson I was under the impression that would mean my library can't be compatible with both 2.3 and 2.4 - that turns out to be false. I've successfully built and tested it on 2.4. I reference Simplfied from %StarcounterBin% directory without specifying version. Copy local is relevant for applications, not libraries.

Do I see something wrong or should we just allow a range of compatibility?

[per-samuelsson]

Do I see something wrong or should we just allow a range of compatibility?

Well, actually, things aren't really straightforward, nor satisfying. There is some legacy involved, and I would really want to improve on what get referenced from standard templates. Ideally, we should strive for just a single reference - "Starcounter". And what ever that one needs will be brought in as secondary dependencies.

In the past, .NET didn't really work like that, and on top of that, code has been added that make types from assemblies like Starcounter.Internal exposed from Starcounter, which in turn will force you to add the reference. That's not how we want it to be.

Let's see if we can improve on this when we get done with 2.3 and start polishing 2.4.

As for what references are needed, and whether they should be private or not, stuff will work dependent somewhat on what you do. For example, why we needed to make the switch to have private assembly references (i.e. Copy Local = true) in 2.4, is b/c we support a new, additional hosting model there - self-hosting. For that to work, it's a necessity for assemblies to be next to the exe. Furthermore, since that is the default for "normal" applications/templates, we wanted to move in that direction for that cause too.

[joozek78]

I'm not concerned by reference being private (Copy Local), because I provide a library. Any application that would use it in 2.4 would need to have Starcounter as a dependency anyway.

stuff will work dependent somewhat on what you do

What do you mean?
I currently see no reason why Authorization library shouldn't be allowed do declare compatibility with 2.3 and 2.4. Change in Starcounter required to support this seems trivial (it isn't case of supporting it really, just recognizing my compatibility).

Is there a reason not to allow it? If so, what exactly? If not, can I expect this to be changed?

[per-samuelsson]

I currently see no reason why Authorization library shouldn't be allowed do declare compatibility with 2.3 and 2.4.

Just to be clear: me neither.

Is there a reason not to allow it? If so, what exactly?

TBH, not much thought was given to libraries in 2.4, only the application project.

The reason there is a compatibility setting was because to function properly for all cases (i.e. including self-hosting), any 2.4-based application must have references set up as they are setup in the 2.4-targeting template. And since we want to make sure we can given proper feedback on what is wrong, when someone take a 2.3-based application project and try run it in 2.4, the compatibility setting was introduced. Using that, we can advice users that they need to do some hands on fiddling when moving 2.3 -> 2.4 for all scenarios to work properly.

Like I said, it's not perfect, but neither is it perfect just to let users go ahead and do whatever and see them fail without having a clue on why they do. In short, 2.4 will get some attention and to improve on this is part of that.

Again: 2.4 is not to be considered stable at this point, and really, I'd even advice not to run on it until we've had the chance to go through these points. It's no magic. Just that we need to throw resources on it, and get improvements done.

If not, can I expect this to be changed?

Like I said, yes, we are about to start this:

Let's see if we can improve on this when we get done with 2.3 and start polishing 2.4.

[joozek78]

Like I said, yes, we are about to start this:

Cool, thanks. I just didn't understand you before. Any idea when this could happen? Is it likely to be few weeks or more like few months?

[per-samuelsson]

Any idea when this could happen? Is it likely to be few weeks or more like few months?

It's a matter of how things get prioritized, which is little up to me. When 2.4 get the priority, we need to come up with some way to solve the rough edges in UX when building projects that target 2.3 and 2.4, and it's not obvious to me if a simple solution exist. Based on those two uncertain parameters, I'd be happy not having to make a guess. 😃