also, not sure why app developers will target both platforms separately...
Too much awake.
@jdom we can't restrict the developer heheh
the same way we care about adding binding redirects or enforce user to add latest nugets, we can't enforce them to have #IF or not give them the ability to run on both environments, who knows what they are up to? :)
maximum common denominator
MDC here heaahahhaha
@jdom and example of that is Performance Counters... the user can add the Nugets for it if they want... but that is completely outside Orleans
What I have in my mind is that we have some pre-canned regular expressions. Then one of them could be name
CurrentOrleansImplementation (I just made this up for the sake of this example). Regex currentImpl = new Regex(@"..."); var files = Directory.GetFiles(ysomePath, "*.dll").Where(path => reg.IsMatch(path)) and then feed this to the new implementation that works with a explicit list of files. This we we could have some predefined ones and one is free to supply ones own ones too. That "currentImpl" thing could, should, be wrapped so that if nothing is given, it works as currently. Or something like that
actually
lets stop talk about both worlds... not it is a single world... .Net Standard
@veikkoeeva that is not necessary
The problem for this Azure strategy MS has is that they don't want to go the cloud. :)
Air gaps and all, factory floor systems built like ships with their compartments having firewalls and so forth.
In factories one problem is, for instance, that although one would like to have more sensors and chips, they would need to leech current from, say, control wires, which easily would cause too much fluctuation. Hmm, I have written about this before, just a sec...
Some of that is true too, naturally.
Which makes the Azure Pack, "user maintained datacentres" (as in Germany) quite a smart idea.
@sergeybykov besides for runtime codegen, why does we actually do that? I know I'm one of the ones which made a lot of voice here to have just the runtime codegen since @ReubenBond started developing it due to the several problems with VS cache, the orleans.codegen.cs not being correctly updated and other issues but, think straight, and given the current scenario of Roslyn, .Net Standard, the new way of "think", why would we need that?
I mean, why we dynamicly load assemblies on silo startup? Runtime codegen is (today) a reason, but that could be made differently... I, and I think most of us, has the grain interfaces and implementation dlls both referenced on silo host so visual studio just put those assemblies (and their direct dependencies) on output... If you don't add the reference, you must copy everything there by yourself, which will probably reduce the productivity while developing your cluster and in production. the only reason dynamic assembly loading IMHO make sense, is if you can hot replace it later on...
I'm just advocating 2 things>
- .Net Standard is an API spec that everyone will have to follow in a very soon future so we should be compliant with it if we want to run xplat
- Dynamic Assembly loading is something that makes not much sense in this scenario since we does not (and don't have plans) to support hot swap of grain assemblies
ok but, by hitting F5, you are going to build it
ok but, who uses that? what is the clear scenario that you dont have a console/worker role today ?
Fundamentally, silo code is a static runtime for app assemblies, so rebuilding it for every app change doesn't make a lot of sense to me.