-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StarcounterVersionCompatibility with multiple SC versions #3
Comments
Just to be able to improve it futher: what exact information are you missing from the referenced troubleshooting section? |
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 |
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. |
@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 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 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. |
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.
What do you mean? Is there a reason not to allow it? If so, what exactly? If not, can I expect this to be changed? |
Just to be clear: me neither.
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.
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? |
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. 😃 |
I have a library which is (AFAIK) compatible with all versions of Starcounter. It currently fails on 2.4 with the following error:
StarcounterVersionCompatibility
?The text was updated successfully, but these errors were encountered: