Имейте в виду, что следующее не предназначено для замены надлежащего решения безопасности.
После игры с этим в течение четырех дней я собрал решение, используя только открытый источник Пакет System.Data.SQLite от NuGet. Я не знаю, сколько защиты это обеспечивает. Я использую его только для своего курса. Это создаст БД, зашифрует его, создаст таблицу и добавит данные.
using System.Data.SQLite;
namespace EncryptDB
{
class Program
{
static void Main(string[] args)
{
string connectionString = @"C:\Programming\sqlite3\db.db";
string passwordString = "password";
byte[] passwordBytes = GetBytes(passwordString);
SQLiteConnection.CreateFile(connectionString);
SQLiteConnection conn = new SQLiteConnection("Data Source=" + connectionString + ";Version=3;");
conn.SetPassword(passwordBytes);
conn.Open();
SQLiteCommand sqlCmd = new SQLiteCommand("CREATE TABLE data(filename TEXT, filepath TEXT, filelength INTEGER, directory TEXT)", conn);
sqlCmd.ExecuteNonQuery();
sqlCmd = new SQLiteCommand("INSERT INTO data VALUES('name', 'path', 200, 'dir')", conn);
sqlCmd.ExecuteNonQuery();
conn.Close();
}
static byte[] GetBytes(string str)
{
byte[] bytes = new byte[str.Length * sizeof(char)];
bytes = System.Text.Encoding.Default.GetBytes(str);
return bytes;
}
}
}
По желанию вы можете удалить conn.SetPassword(passwordBytes);
и заменить его на conn.ChangePassword("password");
, который нужно поместить после conn.Open();
вместо предыдущего. Тогда вам не понадобится метод GetBytes.
Чтобы расшифровать, нужно просто ввести пароль в строку подключения перед открытием вызова.
string filename = @"C:\Programming\sqlite3\db.db";
string passwordString = "password";
SQLiteConnection conn = new SQLiteConnection("Data Source=" + filename + ";Version=3;Password=" + passwordString + ";");
conn.Open();
Веб-сайт:
веб-сайт проект компилируется на лету. Вы заканчиваете с намного большим количеством файлов DLL, которые могут быть болью. Это также дает проблемы, когда у Вас есть страницы или средства управления в одном каталоге, для которых нужно к ссылочным страницам и средствам управления в другом каталоге, так как другой каталог еще не может быть скомпилирован в код. Другая проблема может быть в публикации.
, Если Visual Studio не говорят постоянно снова использовать те же имена, она придумает новые названия файлов DLL, сгенерированных страницами все время. Это может привести к наличию нескольких точных копий файлов DLL, содержащих то же имя класса, которое генерирует много ошибок. Проект веб-сайта был начат с Visual Studio 2005, но это, оказалось, не было чрезвычайно популярно.
веб-приложение:
веб-приложение Проект было создано как дополнение и теперь существует как часть SP 1 для Visual Studio 2005. Основными отличиями является веб-приложение Проект, был разработан для работы подобный веб-проектам, которые поставлялись с Visual Studio 2003. Это скомпилирует приложение в единственный файл DLL во время изготовления. Для обновления проекта он должен быть перекомпилирован, и файл DLL публикуется для изменений для появления.
Другая хорошая функция проекта веб-приложения, намного легче исключить файлы из представления проекта. В проекте веб-сайта каждый файл, который Вы исключаете, переименован с исключенным ключевым словом в имени файла. В веб-приложении Проект проект просто отслеживает который файлы включать/исключать от представления проекта, не переименовывая их, делая вещи намного более опрятными.
статья ASP.NET 2.0 - веб-сайт по сравнению с проектом веб-приложения также приводит причины на том, почему использовать один а не другой. Вот выборка его:
- необходимо ли переместить большие приложения Visual Studio.NET 2003 года в VS 2005? используют проект веб-приложения.
- Вы хотите открыть и отредактировать какой-либо каталог как веб-проект, не создавая файл проекта? проект веб-сайта использования.
- необходимо ли добавить предварительную сборку и шаги постсборки во время компиляции? проект веб-приложения использования.
- необходимо ли создать веб-приложение с помощью нескольких веб-проектов? проект веб-приложения использования.
- Вы хотите генерировать один блок для каждой страницы? проект веб-сайта использования.
- Вы предпочитаете динамическую компиляцию и работающий на страницах, не создавая весь сайт на каждом просмотре страницы? проект веб-сайта использования.
- Вы предпочитаете, чтобы модель кода единственной страницы кодировала - позади модели? проект веб-сайта использования.
веб-приложение Проекты по сравнению с Проектами веб-сайта (MSDN) объясняет различия между проектами веб-приложения и веб-сайтом. Кроме того, это обсуждает конфигурацию, которая будет сделана в Visual Studio.
Это может звучать немного очевидным, но я думаю, что это - что-то, что неправильно понято потому что Visual Studio 2005 только поставлялся с веб-сайтом первоначально. Если Ваши соглашения проекта с веб-сайтом, который справедливо ограничен и не имеет большого логического или физического разделения, веб-сайт, прекрасны. Однако, если это - действительно веб-приложение с различными модулями, где многие пользователи добавляют и обновляют данные, Вы более обеспечены с веб-приложением.
самая большая про из модели веб-сайта - то, что что-либо в эти app_code
раздел динамично компилируется. Можно заставить обновления файла C# без полного повторно развернуться. Однако это прибывает в большую жертву. Много вещей происходит под покрытиями, которыми трудно управлять. Пространствами имен трудно управлять, и определенное использование DLL идет из окна по умолчанию для чего-либо под app_code
, так как все динамично компилируется.
модель веб-приложения не имеет динамической компиляции, но Вы берете под контроль вещи, которые я упомянул.
, Если Вы делаете n-tier разработку, я настоятельно рекомендую модель веб-приложения. При выполнении ограниченного веб-сайта или быстрой и грязной реализации модель веб-сайта может иметь преимущества.
более подробный анализ может быть найден в:
Это зависит от того, что Вы разрабатываете.
А, ориентированный на содержание на веб-сайт, будет иметь довольным, изменение часто и Веб-сайт лучше для этого.
приложение имеет тенденцию хранить свои данные в базе данных и свои страницы и изменение кода редко. В этом случае лучше иметь веб-приложение, где развертыванием блоков намного больше управляют и имеет лучшую поддержку поблочного тестирования.
Одно из основных отличий - то, что Веб-сайты компилируют динамично и создают непрерывные блоки. Сеть applicaitons компилирует в один большой блок.
с различием между этими двумя покончили в Visual Studio 2008.
Существует статья в MSDN, который описывает различия:
Сравнение Проектов веб-сайта и веб-приложения Проекты
BTW: существуют некоторые подобные вопросы о той теме, например:
веб-сайт = использует, когда веб-сайт создается графическими дизайнерами, и программисты только редактируют одну или две страницы
веб-приложение = использование, когда приложение создается программистами, и графические дизайнеры только редактируют один, или два разбил на страницы/отобразил.
веб-сайты могут работаться при использовании любых инструментов HTML, не имея необходимость иметь студию разработчика, поскольку файлы проекта don’t должны быть обновлены, и т.д. веб-приложения являются лучшими, когда команда главным образом использует студию разработчика и существует высокое содержание кода.
(Некоторые ошибки кодирования найдены в веб-приложениях во время компиляции, которые не найдены на веб-сайтах до времени выполнения.)
Предупреждение: я записал этот ответ много лет назад и не использовал Asp.net с тех пор. Я ожидаю, что вещи теперь шли дальше.
веб-сайт - то, что Вы развертываете на веб-сервере ASP.NET, таком как IIS. Просто набор файлов и папок. There’s ничто на веб-сайте, который связывает Вас с Visual Studio (there’s никакой файл проекта). Генерация кода и компиляция веб-страниц (таких как .aspx, .ascx, .master) сделаны динамично во времени выполнения и изменяются на эти файлы, обнаружены платформой и автоматически перекомпилированы. Можно поместить код, который Вы хотите к доля между страницами в специальной папке App_Code, или можно предварительно скомпилировать его и поместить блок в папку Bin.
веб-приложение является специальным проектом Visual Studio. основное различие для веб-сайтов - то, что, когда Вы разрабатываете проект, все файлы кода компилируются в единственный блок, который помещается в каталог bin. Вы don’t развертываете файлы кода на веб-сервере. Вместо того, чтобы иметь специальную папку для общих файлов кода можно поместить их где угодно, точно так же, как Вы сделали бы в библиотеке классов. Поскольку веб-приложения содержат файлы, которые не предназначены, чтобы быть развернутыми, такие как проект и файлы кода, there’s команда Publish в Visual Studio для вывода веб-сайта к указанному местоположению.
совместно использованные файлы кода Развертывания обычно являются плохой идеей, но что doesn’t означают, что необходимо выбрать Web Application. У Вас может быть веб-сайт, который ссылается на проект библиотеки классов, который содержит весь код для веб-сайта. Веб-приложения являются просто удобным способом сделать это.
Эта тема характерна для .aspx и .ascx файлов. Эта тема все менее релевантна в новых средах разработки приложения, таких как ASP.NET MVC и Веб-страницы ASP.NET, которые не используют codebehind файлы.
Путем компиляции всех файлов кода в единственный блок, включая codebehind файлы .aspx страниц и средств управления .ascx, в веб-приложениях, которые необходимо восстановить для каждого небольшого изменения, и Вы не можете внести живые изменения. Это может быть реальной болью во время разработки, так как необходимо продолжать восстанавливать для наблюдения изменений, в то время как с веб-сайтами изменения обнаруживаются временем выполнения, и страницы/средства управления автоматически перекомпилированы.
Наличие времени выполнения справляется, codebehind блоки меньше работы для Вас, так как Вы не должны волноваться о давании уникальных имен страниц/средств управления или организации их в различные пространства имен.
I’m, не говоря развертывающиеся файлы кода всегда является хорошей идеей (особенно не в случае общих файлов кода), но codebehind файлы должны только содержать код, которые выполняют UI определенные задачи, соединяют обработчики событий проводом и т.д. Ваше приложение должно быть разделено на уровни так, чтобы важный код всегда закончился в папке Bin. Если это так, тогда развертывание codebehind файлы нельзя считать вредным.
Другое ограничение веб-приложений - то, что можно только использовать язык проекта. На веб-сайтах у Вас могут быть некоторые страницы в C#, некоторые в VB, и т.д. Никакая потребность в специальной поддержке Visual Studio. That’s красота расширяемости поставщика сборки.
кроме того, в веб-приложениях Вы не получаете обнаружение ошибок на страницах/средствах управления, поскольку компилятор только компилирует Ваши codebehind классы а не код разметки (в MVC, можно зафиксировать это использование опции MvcBuildViews), который компилируется во времени выполнения.
, поскольку веб-приложения являются проектами Visual Studio, Вы получаете некоторые функции, не доступные на веб-сайтах. Например, можно использовать события сборки, чтобы выполнить множество задач, например, уменьшить и/или объединить файлы JavaScript.
Другая хорошая функция, представленная в Visual Studio, 2010 преобразование Web.config . This также не доступен на веб-сайтах. Теперь работает с веб-сайтами в VS 2013.
Здание веб-приложение быстрее, чем создание веб-сайта, особенно для больших сайтов. Это главным образом, потому что веб-приложения не компилируют код разметки. В MVC при установке MvcBuildViews на истинный тогда, он компилирует код разметки, и Вы получаете обнаружение ошибок, которое очень полезно. Вниз сторона - то, что каждый раз Вы создаете решение, оно создает полный сайт, который может быть медленным и неэффективным, особенно если Вы не редактируете сайт. l включают и выключают MvcBuildViews (который требует, чтобы проект разгрузился). С другой стороны, с веб-сайтами можно выбрать, если Вы хотите создать сайт как часть решения или нет. Если Вы выбираете не к, то создание решения очень быстро, и можно всегда нажимать на узел веб-сайта и выбирать Сборку, если you’ve внес изменения.
В проекте веб-приложения MVC у Вас есть дополнительные команды и диалоговые окна для общих задач, как вЂAdd View’, вЂGo К View’, вЂAdd Controller’, и т.д. Они не доступны на веб-сайте MVC.
, Если Вы используете IIS Express в качестве сервера разработки на веб-сайтах, можно добавить виртуальные каталоги. Эта опция не доступна в веб-приложениях.
Восстановление пакета NuGet не работает на веб-сайтах, необходимо вручную установить пакеты, перечисленные на packages.config , Восстановление Пакета теперь работает с веб-сайтами стартовый NuGet 2.7
Если у вас нет особой потребности в динамически компилируемом проекте, не используйте проект веб-сайта .
Почему? Потому что проект веб-сайта поставит вас в тупик, когда вы попытаетесь изменить или понять свой проект. Функции поиска статической типизации (например, поиск использования, рефакторинг) в Visual Studio навсегда применимы для любого проекта разумного размера. Для получения дополнительной информации см. Вопрос о переполнении стека Медленный «Найти все ссылки» в Visual Studio .
Я действительно не понимаю, почему они отказались от веб-приложений в Visual Studio 2005 из-за причиняющего боль, здравомыслия -дренаж, производительность карбункула веб-сайт типа проекта.
Applications are usually compiled before deployment where as the website makes use of the app_code directory. When anything changes in the app code folder the server will re-compile the code. This means that you can add/ change code with a website on the fly.
The advantage of an app is that there is no re-compiling and so initial start up times will be faster.
Я рекомендую вам посмотреть видео Проекты веб-приложений и проекты веб-развертывания на веб-сайте ASP.NET, в котором подробно объясняется разница, это было очень полезно для меня.
Кстати, пусть вас не смущает название, большая часть видео объясняет разницу между проектами веб-сайтов и проектами веб-приложений и почему Microsoft повторно представила проекты веб-приложений в Visual Studio 2005 (как вы, вероятно, уже знаете, изначально он поставлялся только с проектами веб-сайтов, затем проекты веб-приложений были добавлены в SP1). Отличное видео, которое я настоятельно рекомендую всем, кто хочет узнать разницу.