nikhilk / scriptsharp

Script# Project - a C# to JavaScript compiler, to power your HTML5 and Node.js web development.
http://scriptsharp.com
Other
658 stars 182 forks source link

Pulling Script* attributes out of mscorlib to faciliate client/server code sharing #427

Closed imnaseer closed 10 years ago

imnaseer commented 10 years ago

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

nikhilk commented 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.

imnaseer commented 10 years ago

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!

nikhilk commented 10 years ago

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.

imnaseer commented 10 years ago

I see, it wouldn't have been surprising to encounter circular dependencies over there.