Любая ссылка на profilecommon приводит к ошибке. Значение не может быть нулевым.Имя параметра: тип - PullRequest
5 голосов
/ 11 августа 2010

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

В ряде сообщений говорится, чтобы отмечать или снимать флажок с опции «удалить файл app_code.compiled», но, очевидно, это был вариант Visual Studio 2005. В Visual Studio 2010 его нигде нет. В ряде публикаций говорится, что App_Code.dll присутствует в моем каталоге bin. Это присутствует. Я удалил файл app_code.compile вручную, чтобы увидеть, имеет ли это какое-то значение. Я изменил целевой фреймворк с 4.0 на 2.0 и 3.5. Я полностью удалил сайт в IIS, создал другую папку с другим именем и повторно развернул сайт с каждой комбинацией «разрешить обновление этого предварительно скомпилированного сайта» и «Использовать фиксированные имена и одностраничные сборки». Я включил ссылки на System.Web.Profile и System.Web и System.Web.Profile.ProfileCommon. Я создал новый, свежий веб-сайт, ориентированный на .net Framework v4.0, и скопировал этот файл web.config в свое приложение и заново создал записи в своем профиле, чтобы убедиться, что я ничего не подделал в файле конфигурации. Я зажег свечи и использовал чары вуду. Я молился Я буквально перепробовал каждое мыслимое предложение в каждой ветке форума, касающееся этой ошибки, на первых пяти страницах или около того возвратов как в Google, так и в bing. Я провел 14 дней, почти ничего не делая, но пытаясь заставить этот веб-сайт работать без этой ошибки.

В одном сообщении говорится, что в каталоге bin есть ссылка на app_code.dll. Я не знаю, как это сделать, поскольку он создается динамически.

У кого-нибудь есть свежие идеи по этому поводу?

Ответы [ 3 ]

4 голосов
/ 13 августа 2010

Хорошо, я много читал и экспериментировал на эту тему, и я думаю, что собрал и скомпилировал достаточно информации, чтобы помочь тем, кто может наткнуться на эту тему при поиске этой ошибки. Что я сделаю, так это просто предложу разговорное объяснение, за которым последуют несколько ссылок на очень актуальную информацию.

Существуют две различные методологии веб-дизайна, поддерживаемые Visual Studio; веб-приложения и веб-сайты. Это относится и к 2005, 2008 и 2010 гг. Такое разделение принципов проектирования, по-видимому, обусловлено тем фактом, что Visual Studio 2003 поддерживала только модель веб-приложения, и эта модель была изменена с выпуском Visual Studio 2005, а затем, чтобы Чтобы совместить принципы проектирования с предыдущими версиями, в Visual Studio 2005 была добавлена ​​методология веб-приложений, что создало очень запутанный путь для разработчиков, очевидно, даже с уважаемыми уровнями квалификации.

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

Кроме того, чтобы еще больше сбить с толку, и это меня смутило, профили не будут работать с моделью веб-сайта, если сайт публикуется с помощью параметра меню Build -> Publish Web Site, если (возможно, сначала он предварительно компилируется вручную, а затем предварительно скомпилированные dll копируются через «сайт копирования» или FTP, или как вы используете. Предварительная компиляция, по-видимому, выполняется через командную строку. У меня есть ссылка с инструкциями о том, как это сделать ниже. Но опять же, я сам не проверял это, поэтому не знаю, поможет ли это.

Причина, по которой профили не работают с методом развертывания Build -> Publish Web Site, заключается в том, что класс ProfileCommon создается динамически со свойствами профиля, которые вы определяете в веб-конфигурации, когда IIS динамически компилирует вашу страницу при первом запуске. Доступ Если вы используете опцию «build -> publish web site», он прекрасно компилирует ваши DLL, но не создает этот класс для вас.

Честно говоря, я не уверен, почему опция Build -> Publish Web Site в первую очередь включена в модель сайта. Исходя из всего, что я прочитал, суть модели «Веб-сайт против веб-приложения» заключается в том, чтобы сделать интерфейс ASP.net более похожим на традиционный опыт веб-разработки, где ваши файлы могут быть отредактированы на вашем компьютере и переданы по FTP на сервер или могут просто отредактируйте на сервере. Да, они должны быть скомпилированы до того, как к ним будет получен доступ, но эта компиляция, по замыслу, происходит динамически, и, по-видимому, если вы сначала компилируете сайт, а затем загружаете его, вы компилируете его без динамического создания класса ProfileCommon и, следовательно, эффективно убираете один из них. отличных особенностей подхода asp.net к дизайну сайтов.

Существует ряд сообщений, в которых люди выражают озабоченность по поводу безопасности своего кода, потому что использование модели веб-сайта и копирование их файлов на сервер для динамической компиляции означает, что файлы с исходным кодом находятся на сервере в предварительно скомпилированном виде. государство. Однако я просто не вижу разницы между этим и любым другим более традиционным языком веб-сценариев, таким как Perl, PHP или даже классический ASP. На этих языках код находится так же уязвимо. Любой код уязвим на неверно настроенном сервере. Более того, даже если ваш код скомпилирован, хакер, способный обойти безопасность хорошо сконфигурированного сервера IIS и получить доступ к исходным файлам, может также получить доступ к вашим скомпилированным файлам, а затем просто запустить их через ILDASM. Так что, если они не профессионально запутаны, какая разница?

Итак, из того, что яЕсли вы хотите использовать профили на своем веб-сайте asp.net, создайте свой сайт как проект веб-сайта против проекта веб-приложения и скопируйте его на свой сервер вместо публикации через меню сборки.Возможно, вы сможете предварительно скомпилировать его, а затем опубликовать (не уверен насчет этого), но я знаю, что простое копирование и возможность динамической компиляции работает.

Если я что-то упустил и есть другой способЯ хотел бы прочитать об этом.Между тем вот несколько невероятно полезных ссылок.Огромное спасибо 5arx за настройку моего пути:

http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx

http://msdn.microsoft.com/en-us/library/dd547590.aspx

http://msdn.microsoft.com/en-us/library/ms227972.aspx

3 голосов
/ 11 августа 2010

Вы говорите, что не можете получить доступ к профилю в коде? Если да, можете ли вы опубликовать какой-нибудь код / ​​псевдокод? Я думаю, что это проблема, с которой я столкнулся на прошлой неделе (и исправил) ... - 5arx 11 минут назад

На прошлой неделе была похожая проблема - преобразование проекта веб-сайта ASP.Net в проект веб-приложения. В первом случае профиль определяется декларативно в web.config. Однако у проектов веб-приложений возникают проблемы с доступом к динамически генерируемой DLL-файлу app_code (поскольку он не создается .Net до времени выполнения). Обходной путь должен получить доступ к свойствам профиля таким образом:

ComplexProfileProperty _cpp = (ComplexProfileProperty)HttpContext.Current.Profile.GetPropertyValue("valuename"); 

Hth

извиняюсь, если я полностью неправильно понял ваш вопрос - трудно быть уверенным без примеров кода :-)

1 голос
/ 11 августа 2010

Полагаю, вы смотрели документацию - здесь и здесь и здесь .

Это звучит как некоторые ошибки, которые ямы столкнулись с попыткой доступа / установки свойств анонимного пользователя.Есть довольно много вещей, которые нельзя сделать с помощью anon.users.

Существуют ли другие ошибки, связанные с профилями / членством?Это может быть проблема с таблицами БД или идентификатором приложения / идентификатором пользователя.Context.Request.AnonymousID не обязательно отражает что-либо в БД, из того, что я обнаружил при отладке проблем с Profile.

Если вы действительно застряли, вы можете попробовать получить источник для .NetFramework и отладка в нем.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...