Какие файлы в Визуальном проекте Studio C# не должны быть имеющими версию?
Я искал динамическое решение и потратил 2 дня, пытаясь найти разные решения. Это решение будет поддерживать японские символы и другие стандартные наборы символов
private static string Decode(string input, string bodycharset) {
var i = 0;
var output = new List();
while (i < input.Length) {
if (input[i] == '=' && input[i + 1] == '\r' && input[i + 2] == '\n') {
//Skip
i += 3;
} else if (input[i] == '=') {
string sHex = input;
sHex = sHex.Substring(i + 1, 2);
int hex = Convert.ToInt32(sHex, 16);
byte b = Convert.ToByte(hex);
output.Add(b);
i += 3;
} else {
output.Add((byte)input[i]);
i++;
}
}
if (String.IsNullOrEmpty(bodycharset))
return Encoding.UTF8.GetString(output.ToArray());
else {
if (String.Compare(bodycharset, "ISO-2022-JP", true) == 0)
return Encoding.GetEncoding("Shift_JIS").GetString(output.ToArray());
else
return Encoding.GetEncoding(bodycharset).GetString(output.ToArray());
}
}
. Затем вы можете вызвать функцию с помощью
Decode("=E3=82=AB=E3=82=B9=E3", "utf-8")
. Первоначально было найдено здесь
9 ответов
DI - это свойство среды выполнения, требующей динамической привязки. Я новичок в Obj-C и Cocoa, поэтому могу говорить вне очереди. Если я чего-то не упускаю, я не понимаю, как можно реализовать DI, кроме как путем интерпретации Obj C, а не его компиляции, или путем изменения среды выполнения.
Я подозреваю, что DI-подобное поведение IB связано с тем, что существует специфическая для домена среда выполнения, связанная с приложениями, созданными с ее помощью.
Я рад, что меня поправили.
Категории кажутся реализацией миксинов, позволяющих динамическую отправку методов делегату. Довольно круто и похоже на концепцию интерфейса Java, хотя детали отличаются, и из следующего, я не вижу, можно ли определять константы в категории, хотя поля-члены не могут.
obj
* .suo
* .user
_Resharper * (если у вас Resharper )
Включите
*. sln
* .csproj
Вы также можете проверить файл .gitignore для проектов Visual Studio на github.
Версии не должны быть:
- .csproj.user - это настройки файла проекта пользователя (например, запускаемый проект)
- .suo - настройки файла решения пользователя
Должно быть versioned:
- .sln - это сам файл решения (какие проекты он содержит и т. д.)
- .csproj - это файл проекта
Я не уверен насчет "contentproj", но похоже, что это файл проекта, который должен быть под svn.
.csproj определяет структуру проекта. Это жизненно важно.
Это то, что я добавляю в свой глобальный список игнорирования в Tortoise SVN:
*.suo *.user bin obj *.pdb *.cache *_svn *.svn *.suo *.user *.build-res TestResults _ReSharper*
Just to add, anything that gets regenerated at build time, should be excluded. For example, files generated from the prebuild event or in some cases a custom tool.
Требуется ...
*. Sln - файл решения содержит ссылки на все проекты и зависимости между проектами.
* .csproj - сами файлы проекта. Они сообщают, какие файлы включены в проект, ссылки и этапы сборки проекта.
Не ...
*. Suo - это файл пользовательских настроек ...
Файл .sln определяет ваше решение вместе с файлами .proj (по одному для каждого проекта), поэтому сохраните их в своем svn!
Файл .suo можно пропустить (личные настройки - в любом случае двоичный), а также папки bin или obj. Также файлы .cache можно оставить.
Мы также работаем с Visual Studio C # и SVN, и я не знаю обо всем файлы проекта, но мы исключаем только полный каталог bin .
Я опускаю файл параметров пользователя решения Visual Studio (* .suo) и каталоги двоичных файлов, поскольку они перекомпилируются каждый раз при сборке решения ( bin и obj папок).
Вам определенно нужны файлы csproj ... Вы можете попробовать AnkhSVN или VisualSVN, эти надстройки VS добавляют только необходимые файлы в SVN.
Или вы можете удалить файлы из своей структуры каталогов пока оно не перестанет загружаться.
Я предлагаю поэкспериментировать, потому что это отличный способ узнать, как решение структурируется с помощью VS.