скрипт #, как диагностировать «Убедитесь, что ваш исходный код C # компилируется и вы не используете неподдерживаемую функцию» - PullRequest
Новая
       8

скрипт #, как диагностировать «Убедитесь, что ваш исходный код C # компилируется и вы не используете неподдерживаемую функцию»

2 голосов
/ 28 октября 2011

Я получаю это сообщение

«Убедитесь, что ваш источник C # скомпилирован и вы не используете неподдерживаемую функцию»

И не знаю, как понять, что я делаю неправильно. Кто-нибудь знает?

Я понимаю общую концепцию того, что говорится, но мне нужно что-то более конкретное

РЕДАКТИРОВАТЬ: Я не просил, чтобы конкретный случай диагностировали. Я спрашивал, есть ли переключатель компилятора, который дал бы больше информации

В любом случае вот код ошибки 

    [ScriptName("Ext")]
    [IgnoreNamespace]
    [Imported()]
    public partial class Ext //: ext.data.Store
    {
        [ScriptName("create")]
        public static object Create(string name, object config)
        {
            return null;
        }
    }    
public sealed class viewport
    {

        public static viewport MakeViewPort()
        {
            return new viewport();
//return (viewport)extwrap.Ext.Create("Ext.container.ViewPort", null);
        }
    }
    public class Class1
    {
        public void foo()
        {

            jslate.viewport vp = jslate.viewport.MakeViewPort(); <=== fails here


        }
    }

Я пытаюсь обойти тот факт, что extjs4 не позволяет

var win = new Ext.Window

вместо этого вы делаете 

var win = Ext.create('Ext.window')

Вы можете увидеть различные попытки сделать это. Все компилируются, но отскакивают от S #

Ответы [ 4 ]

1 голос
/ 06 ноября 2011

Я часто обнаруживал, что Script Sharp будет молча работать, если в коде есть детали пространства имен.

Я не уделил достаточного внимания тому, чтобы вспомнить, в каких случаях это расстраивает. Но обычно эти сбои сборки происходят, когда я сравниваю Enums (т.е. if (enum1 == EnumTypes.Something))

Или когда вы ссылаетесь на что-то с префиксом пространства имен. то есть Foo.Bar bar = Foo.Bar.Create (бла);

Я не могу вспомнить, было ли это чем-то, что точно провалилось - но это что-то похожее на это

1 голос
/ 28 октября 2011

Самая распространенная причина, по которой я вижу эту ошибку, - это частично определенное имя типа, которое в Script # 0.7.3 не поддерживается полностью.Например: 

namespace NSA.NSB
{
    class MyType { ... }
}

...

NSB.MyType myObj1 = new NSB.MyType(); // generates the error
NSA.NSB.MyType myObj2 = new NSA.NSB.MyType(); // does not generate the error

Говоря более широко , я заметил, что иногда подробные сообщения об ошибках не всплывают до самого Visual Studio.Если вместо этого вы используете компилятор командной строки (ssc.exe), иногда вы можете увидеть более подробное сообщение об ошибке или любые исключительные ситуации, которые помогут отладить причину ошибки.Один из моих больших проектов Script # иногда отбрасывает ошибку, которую вы видите, поэтому я на самом деле держу .bat рядом с моим .csproj, чтобы отладить причину.

Мой скрипт командной строки обычно выглядитвот так, хотя вы можете запросить ssc для всех его параметров. 

@SET SS="c:\program files (x86)\ScriptSharp\v1.0"
%SS%\ssc /debug ^
/D:MYDEFINE ^
/ref:%SS%\Framework\mscorlib.dll ^
/ref:%SS%\Framework\Script.Web.dll ^
/ref:%SS%\Framework\Script.jQuery.dll ^
/out:Output.js ^
.\Properties\AssemblyInfo.cs ^
.\RestOfMySourceCode.cs ^
...
1 голос
/ 30 октября 2011

Ошибка, с которой вы столкнулись, это тот случай, когда, к сожалению, произошел сбой компилятора, и, следовательно, он не смог сообщить о более совершенной ошибке. Вы увидите похожие внутренние ошибки компилятора для других языков (в том числе c #), если вы сделаете что-то, что делает его действительно несчастным. Хотя я полностью согласен с тем, что было бы полезно генерировать более совершенные ошибки везде, где это возможно, в некоторых случаях обнаружение неподдерживаемой конструкции так же хорошо, как выполнение работы по поддержке конструкции.

Я надеюсь, что вы можете использовать последнюю версию компилятора - ситуация постоянно улучшается при обработке ошибок от сборки к сборке ... например, создание отчетов о c # line #, компиляция остальной части кода C # и генерация заявление об ошибке в результирующем javascript для сбойной строки вместо подхода «все или ничего», а также улучшенное сообщение об ошибках в пути msbuild.

В этом конкретном случае я подозреваю, что за ошибками стоит использование имен типов с указанием пространства имен (extwrap.Ext и jslate.viewport) в приведенном выше коде. На самом деле это ограничение было указано в скрипте # readme (который раньше был доступен, но был удален, так как часть документа устарела ... извините за это ... нужно что-то вернуть в сеть или включить в настройке.)

Кроме того, как вы понимаете, переосмысление некоторых основных частей скриптового подхода к компиляции раз и навсегда решает множество проблем. Я хотел бы начать это, а затем опубликовать исходники для компилятора. Внедрение этого фундаментального изменения является следующим шагом в создании полноценного проекта на GitHub ... для тех, кто отслеживает прогресс в этом направлении.

0 голосов
/ 28 октября 2011

Я представляю, что Script #, вероятно, выводит оскорбительную строку #, не так ли?Это может дать вам подсказку:)

Вот пример подобного предупреждения из Script # Blog:

http://www.nikhilk.net/ScriptSharp-Update-Nov-2009.aspx

Форум в stackoverflow делаетне позволяет мне создавать новый тег scriptsharp, поэтому я публикую здесь.Похоже, что получение значений переменных среды еще не поддерживается.Использование System.Gadgets.EnvironmentService.GetEnvironmentVariable для создания «System.Environment.getEnvironmentVariable (..)» в JS приводит к ошибке компиляции «Проверьте, что ваш источник C # компилируется и что вы не используете неподдерживаемую функцию."

Также я вижу, что реализация просто возвращает ноль.Если не поддерживается, могу ли я как-то встроить этот JS в код?

Приветствия Брюс

PS: !!!! ПОКАЗАТЬ КОД США !!!!

...