R# and Script#

Hello.

I really like R# and have just tried 3.0.2. it's really nice. But there
is another very good extension for VS 2005, called Script#. Script# is a
special framework (class library) replacing .NET framework (FCL) and is
used by the Script# compiler ssc. ssc takes code written in C# and
produces JavaScript instead of MSIL. For detailed informations please
have a look at the Script# project page at

http://projects.nikhilk.net/Projects/ScriptSharp.aspx.

Script# works fine as well as R# does. But both together do not work
correctly, maybe because R# gets confused in Script# code editor windows
because they use sscorlib instead of mscorlib.

It would be very nice if you could add support for Script# and it's
editors, which shouldn't be so difficult because it is C#, or as a first
patch disable R# for Script# code editor windows to get working both
side by side.

I've tried Script# 0.3.0 with R# 2.5.2 and 3.0.2 on two systems with VS
2005 and XP Pro SP2 (one with VS Prof., the other with VS Team Suite).
None of the combinitions worked, whereas 3.0.2 was better than 2.5.2
(which throwed exceptions repeatingly in Script# windows).


Thanks and kind regards,

Marco

12 comments
Comment actions Permalink

Hello Marco,

could you please clarify what are the problems more precisely - i.e. what
you mean when you're telling that
"R# gets confused in Script# code editor windows because they use sscorlib
instead of mscorlib"?

I've tried to download Script# and created a couple of new projects using
its project templates, and I've not
encountered any red code which could be false errors from ReSharper.

Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


Hello.

I really like R# and have just tried 3.0.2. it's really nice. But
there is another very good extension for VS 2005, called Script#.
Script# is a special framework (class library) replacing .NET
framework (FCL) and is used by the Script# compiler ssc. ssc takes
code written in C# and produces JavaScript instead of MSIL. For
detailed informations please have a look at the Script# project page
at

http://projects.nikhilk.net/Projects/ScriptSharp.aspx.

Script# works fine as well as R# does. But both together do not work
correctly, maybe because R# gets confused in Script# code editor
windows because they use sscorlib instead of mscorlib.

It would be very nice if you could add support for Script# and it's
editors, which shouldn't be so difficult because it is C#, or as a
first patch disable R# for Script# code editor windows to get working
both side by side.

I've tried Script# 0.3.0 with R# 2.5.2 and 3.0.2 on two systems with
VS 2005 and XP Pro SP2 (one with VS Prof., the other with VS Team
Suite). None of the combinitions worked, whereas 3.0.2 was better than
2.5.2 (which throwed exceptions repeatingly in Script# windows).

Thanks and kind regards,

Marco



0
Comment actions Permalink

Hello Dmitry,

Intellisense doesn't work at all, code completion with Ctrl + Space
sometimes, and after code completion and sometimes else the cursor jumps
to unintended positions (e. g. to EOL instead of the end of the variable
or type name). Or the cursor "physically" is at the correct position but
visually appears some chars right of the position it is.

Attached is a screenshot from my HelloWorld scriptlet I've copied 1:1
from the Script# documentation.

I guess that Script# requires special code rules (methods must be
non-static even if they could be static from a C#/.NET view. Using
references must exist even if they are not used directly in the code
file, because they will be compiled/"translated" in corresponding
JavaScript code which is required. Contructor might need a
ScriptletArguments parameter even if it is not used in the code etc. The
red marker "Ambigious reference" might result in refenrecing mscorlib
and sscorlib. But that's a Website and I do not know how to set that
mscorlib should not be used as it is possible with class library
projects etc. (because of course mscorlib is not listed under
compilation/assemblies in web.config).

Maybe you can talk with Nikhil Kothari about what you can do and also
what he can do to recognize that's Script# and not just C# and which
rules apply to Script# code.

Marco

Hello Marco,

could you please clarify what are the problems more precisely - i.e.
what you mean when you're telling that
"R# gets confused in Script# code editor windows because they use
sscorlib instead of mscorlib"?

I've tried to download Script# and created a couple of new projects
using its project templates, and I've not encountered any red code which
could be false errors from ReSharper.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


>> Hello.
>>
>> I really like R# and have just tried 3.0.2. it's really nice. But
>> there is another very good extension for VS 2005, called Script#.
>> Script# is a special framework (class library) replacing .NET
>> framework (FCL) and is used by the Script# compiler ssc. ssc takes
>> code written in C# and produces JavaScript instead of MSIL. For
>> detailed informations please have a look at the Script# project page
>> at
>>
>> http://projects.nikhilk.net/Projects/ScriptSharp.aspx.
>>
>> Script# works fine as well as R# does. But both together do not work
>> correctly, maybe because R# gets confused in Script# code editor
>> windows because they use sscorlib instead of mscorlib.
>>
>> It would be very nice if you could add support for Script# and it's
>> editors, which shouldn't be so difficult because it is C#, or as a
>> first patch disable R# for Script# code editor windows to get working
>> both side by side.
>>
>> I've tried Script# 0.3.0 with R# 2.5.2 and 3.0.2 on two systems with
>> VS 2005 and XP Pro SP2 (one with VS Prof., the other with VS Team
>> Suite). None of the combinitions worked, whereas 3.0.2 was better than
>> 2.5.2 (which throwed exceptions repeatingly in Script# windows).
>>
>> Thanks and kind regards,
>>
>> Marco
>>





Attachment(s):
R# marker in Script# Window.jpg
0
Comment actions Permalink

Marco,

looks like the problem is caused by ReSharper not respecting the 'NoStdLib'
compiler option which disabled referencing MSCORLIB.
I've created an issue for this: http://www.jetbrains.net/jira/browse/RSRP-45583

Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


Hello Dmitry,

Intellisense doesn't work at all, code completion with Ctrl + Space
sometimes, and after code completion and sometimes else the cursor
jumps to unintended positions (e. g. to EOL instead of the end of the
variable or type name). Or the cursor "physically" is at the correct
position but visually appears some chars right of the position it is.

Attached is a screenshot from my HelloWorld scriptlet I've copied 1:1
from the Script# documentation.

I guess that Script# requires special code rules (methods must be
non-static even if they could be static from a C#/.NET view. Using
references must exist even if they are not used directly in the code
file, because they will be compiled/"translated" in corresponding
JavaScript code which is required. Contructor might need a
ScriptletArguments parameter even if it is not used in the code etc.
The red marker "Ambigious reference" might result in refenrecing
mscorlib and sscorlib. But that's a Website and I do not know how to
set that mscorlib should not be used as it is possible with class
library projects etc. (because of course mscorlib is not listed under
compilation/assemblies in web.config).

Maybe you can talk with Nikhil Kothari about what you can do and also
what he can do to recognize that's Script# and not just C# and which
rules apply to Script# code.

Marco

>> Hello Marco,
>>
>> could you please clarify what are the problems more precisely - i.e.
>> what you mean when you're telling that
>> "R# gets confused in Script# code editor windows because they use
>> sscorlib instead of mscorlib"?
>> I've tried to download Script# and created a couple of new projects
>> using its project templates, and I've not encountered any red code
>> which
>> could be false errors from ReSharper.
>> Dmitry Shaporenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>> Hello.
>>>
>>> I really like R# and have just tried 3.0.2. it's really nice. But
>>> there is another very good extension for VS 2005, called Script#.
>>> Script# is a special framework (class library) replacing .NET
>>> framework (FCL) and is used by the Script# compiler ssc. ssc takes
>>> code written in C# and produces JavaScript instead of MSIL. For
>>> detailed informations please have a look at the Script# project page
>>> at
>>>
>>> http://projects.nikhilk.net/Projects/ScriptSharp.aspx.
>>>
>>> Script# works fine as well as R# does. But both together do not work
>>> correctly, maybe because R# gets confused in Script# code editor
>>> windows because they use sscorlib instead of mscorlib.
>>>
>>> It would be very nice if you could add support for Script# and it's
>>> editors, which shouldn't be so difficult because it is C#, or as a
>>> first patch disable R# for Script# code editor windows to get
>>> working both side by side.
>>>
>>> I've tried Script# 0.3.0 with R# 2.5.2 and 3.0.2 on two systems with
>>> VS 2005 and XP Pro SP2 (one with VS Prof., the other with VS Team
>>> Suite). None of the combinitions worked, whereas 3.0.2 was better
>>> than 2.5.2 (which throwed exceptions repeatingly in Script#
>>> windows).
>>>
>>> Thanks and kind regards,
>>>
>>> Marco
>>>


0
Comment actions Permalink

I've created an issue for this:
http://www.jetbrains.net/jira/browse/RSRP-45583


This was already reported 4 months ago:
http://www.jetbrains.net/jira/browse/RSRP-36713

Any idea when this will finally be fixed?


Nato


0
Comment actions Permalink

Hello Nathan,

thanks for pointing this out. In the latest build of 3.0.2 we've supported
the compiler option telling not to reference MSCORLIB. So you're welcome
to try the next EAP build as soon as it is published.


Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"



>> I've created an issue for this:
>> http://www.jetbrains.net/jira/browse/RSRP-45583
>>

This was already reported 4 months ago:
http://www.jetbrains.net/jira/browse/RSRP-36713
Any idea when this will finally be fixed?

Nato



0
Comment actions Permalink

Thanks Dmitry. So far, this seems to be working well in build 504 for
standalone Script# projects. At least in my five minutes of playing with it
so far. This rocks.

However, I am still noticing the other half of the problem reported in
RSRP-36713 -- namely when you have multiple projects open in a solution,
where some of the projects are Script# (and hence are set to not reference
MSCORLIB as their standard types are provided by AACORLIB/SSCORLIB), and
some of them are regular server side C# project (which do reference
MSCORLIB).

The Script# projects are all parsing correctly, and everything is golden.

However, when viewing a regular C# file in the /non/-Script# project in the
same solution, Resharper will flag most types with an error specifying that
"Module 'aacorlib, version...' should be referenced." :( At first I
thought it was only types that were overlapping between MSCORLIB and
AACORLIB, but it actually appears to happen to a large majority of the types, including totally standalone types (like enums).

While it is possible to workaround this -- by seperating out the projects
into different solutions, or unload all of the Script# projects and refresh
the Resharper cache's -- it's also a fair bit annoying.

Any chance you could take a look?

Donovan

0
Comment actions Permalink

Ping.

(Apologies for the nag, but I did want to make sure this made it to someone's attention. Anyone?)

0
Comment actions Permalink

I'm having this same problem with Script#.
It also occurs with Silverlight projects as they also use the same priciple, with multiple projects with different Core Assemblies.

Is there any timeframe available in which this will be fixed ?

gr,
Rj

0
Comment actions Permalink

Hello Robertjan and Donovan,

could you please clarify the problems you're experiencing? In the original
thread,
the problem was that ReSharper didn't support the compiler option for omitting
the reference
to the MSCorlib assembly. This has been fixed in 3.0.2.


Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


I'm having this same problem with Script#. It also occurs with
Silverlight projects as they also use the same priciple, with multiple
projects with different Core Assemblies.

Is there any timeframe available in which this will be fixed ?

gr,
Rj



0
Comment actions Permalink

Yeah:

It's essentially the other half of the problem reported in RSRP-36713 (see the comments) -- have multiple projects in your solution using different standard libraries. In particular, have a solution with a regular C# project in it, and a Script# project in it. (The former will reference MSCORLIB, and the latter will reference AACORLIB/SSCORLIB). Alternatively, you can repro the same by having silverlight projects and regular C# projects (as they reference different Core assemblies).

In such a situation, the Script# projects will all parse correctly, and everything is golden per your bug fix as of 3.0.2.

However, when viewing a file file in the /non/-Script# project, Resharper will flag most types with an error specifying that
"Module 'aacorlib, version...' should be referenced." At first I
thought it was only types that were overlapping between MSCORLIB and
AACORLIB, but it actually appears to happen to a large majority of the types, including totally standalone types (like enums).

While it is possible to workaround this -- by seperating out the projects
into different solutions, or unload all of the Script# projects and refresh
the Resharper cache's -- it's also a fair bit annoying.

In essence, it appears that Resharper is letting the symbols from the core libraries that a project references leak over into the other projects in the solution.

Care to take a look?

Donovan

0
Comment actions Permalink

Hello Donovan,

OK, I see now what you mean. The problem with multiple 'core' (in a sense
that it contains the basic types like Int32 etc)
assemblies referenced in one solution is actually a very old one and dates
back to the very first version of ReSharper. Basically,
ReSharper assumes that there is only one definition of, say, System.Int32
or System.String in the solution and gets confused
when it observes multiple definitions.

Unfortunately, there is no good workaround for this except for separating
projects referencing different 'core' assemblies into
separate solutions which is apparently not always feasible. In 4.0 we've
revised the relevant parts of the architecture and removed
this limitation, so in 4.0 the problem will finally be fixed.

Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


Yeah:

It's essentially the other half of the problem reported in RSRP-36713
(see the comments) -- have multiple projects in your solution using
different standard libraries. In particular, have a solution with a
regular C# project in it, and a Script# project in it. (The former
will reference MSCORLIB, and the latter will reference
AACORLIB/SSCORLIB). Alternatively, you can repro the same by having
silverlight projects and regular C# projects (as they reference
different Core assemblies).

In such a situation, the Script# projects will all parse correctly,
and everything is golden per your bug fix as of 3.0.2.

However, when viewing a file file in the /non/-Script# project,
Resharper will flag most types with an error specifying that "Module
'aacorlib, version...' should be referenced." At first I thought it
was only types that were overlapping between MSCORLIB and AACORLIB,
but it actually appears to happen to a large majority of the types,
including totally standalone types (like enums).

While it is possible to workaround this -- by seperating out the
projects into different solutions, or unload all of the Script#
projects and refresh the Resharper cache's -- it's also a fair bit
annoying.

In essence, it appears that Resharper is letting the symbols from the
core libraries that a project references leak over into the other
projects in the solution.

Care to take a look?

Donovan



0
Comment actions Permalink

Hello Donovan,

I think it is fixed in ReSharper 4.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


DL> Thanks Dmitry. So far, this seems to be working well in build 504
DL> for standalone Script# projects. At least in my five minutes of
DL> playing with it so far. This rocks.
DL>
DL> However, I am still noticing the other half of the problem reported
DL> in RSRP-36713 -- namely when you have multiple projects open in a
DL> solution, where some of the projects are Script# (and hence are set
DL> to not reference MSCORLIB as their standard types are provided by
DL> AACORLIB/SSCORLIB), and some of them are regular server side C#
DL> project (which do reference MSCORLIB).
DL>
DL> The Script# projects are all parsing correctly, and everything is
DL> golden.
DL>
DL> However, when viewing a regular C# file in the /non/-Script# project
DL> in the same solution, Resharper will flag most types with an error
DL> specifying that "Module 'aacorlib, version...' should be
DL> referenced." :( At first I thought it was only types that were
DL> overlapping between MSCORLIB and AACORLIB, but it actually appears
DL> to happen to a large majority of the types, including totally
DL> standalone types (like enums).
DL>
DL> While it is possible to workaround this -- by seperating out the
DL> projects into different solutions, or unload all of the Script#
DL> projects and refresh the Resharper cache's -- it's also a fair bit
DL> annoying.
DL>
DL> Any chance you could take a look?
DL>
DL> Donovan
DL>


0

Please sign in to leave a comment.