Closed imnaseer closed 10 years ago
Well, you could achieve this by thinking the other way around too... that is by having a stub .net assembly defining these attributes and exist for your regular .net-compiled code.
Or ifdefs ... though those tend to get ugly quickly, hence I don't really consider that to be a viable solution.
The reason pulling them out of mscorlib doesn't work in the case of script# is that types within mscorlib themselves use these attributes.
I was aware of mscorlib using them and was planning on making mscorlib depend on the assembly which defined them.
Your solution is way less work and unblocks me quickly. Thanks!
Good to hear it works for you.
Note I suspect you'd have a bunch of issues trying to make mscorlib depend on another assembly ... since the attributes depend on types in mscorlib themselves. You wouldn't have been able to make it work without introducing circular dependencies.
I see, it wouldn't have been surprising to encounter circular dependencies over there.
I want to share common code between the server (written in C#) and the browser. I've two separate C# projects which share the same code files with the server project linking against the .NET mscorlib and the client project linking against the Script# mscorlib. This arrangements works fine if I don't annotate any of the common classes with a Script* attribute (eg. [ScriptName]) but breaks if I want to annotate the common classes as the server project can't have two conflicting versions of the mscorlib assembly.
Is there a recommended way of achieving what I'm after that I'm missing?
If not then can factoring out the ScriptMetadata.cs (in CoreLib) to a different assembly enable this use case?
Thanks