Станислав Макаров

1) сразу попробовать DownloadFileTaskAsync, с тасками работать проще;
2) дожидаться завершения таска на скачку одного файла перед запуском следующего;
3)

Новый поток? Пробовал. Не двигается прогресс бар.

Работать с контролами только из GUI-потока. Читать про SynchronizationContext.

P.S. ОС у пользователей естественно windows (7,8)

GUI - когда-то пару проектов на winform

C#

ну так чего думать-то. Посмотрите на WPF, на EntityFramework/NHibernate и вперед. Ну или если есть возможность и время, разбейте на веб-сервис (можно написать на чем угодно) и веб-клиент (собсно, ваше десктопное приложение).

C SQL базой правильно такого не делать. В смысле - не изменять схему SQL базы данных по запросам пользователя. Нужно подумать, почему возникает такая необходимость, возможно часть данных нужно хранить в документно-ориентированной БД.

Ой, а можно мне вспомнить беззаботные юношеские времена?

Нужны знания о том, как правильно пользоваться сторонними библиотеками (любыми), написанными на C/C++ - как их подключать в проект и как работать с их API так, чтобы не наломать дров. Для этого необходимо понимать управление памятью в C++, понимать что такое жизненный цикл объекта и еще некоторые мелочи (например, что не стоит выделять память в одном двоичном модуле, а высвобождать в другом).

При запросе к коллекции сервер mongodb уже работает или запускается призапуске сервера nodejs например.

Кажется, вы не работали не только с nosql, а вообще с любыми многопользовательскими СУБД. Монга это не SQLite: запускается демон и слушает порт на подключения по сети.

И mongodb устанавливается в сис. файлы?

Вообще вопрос не понял. Что для вас "системные файлы"?

Если установить в директорию с проектом или это не играет роли куда и как установилась mongodb.

Я думаю, в директорию с проектом не стоит устанавливать.

Если же в любом, то как можно указать папку с коллекциями, через mongod?

Ну вроде бы да, в любой нормальной клиент-серверной СУБД директория к данным настраивается.

Вообщем, почитайте отсюда что-ли https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B8%D... , вам нужно понять, что монга со своими данными живет сама по себе, а ваше приложение - само по себе, и взаимодействуют они с помощью TCP. Следовательно, нет никакого смысла как-либо связывать директорию с проектом и директорию с БД Монги, т.к. они могут находиться на совершенно разных машинах.

1) прикладной уровень (HTTP) использует TCP как сервис (а именно - какое-либо API, предоставляемое ОС, например сокеты Беркли) и выражает желание отправить некоторое количество данных в пункт Б; в теории объем данных может быть любым, т.к. задача именно TCP - разбить данные на куски и прилепить к ним свой заголовок. Полученные куски с заголовками называются TCP-сегментами; в этих заголовках есть все, что необходимо для обеспечения всех гарантий, которые даёт TCP, а именно: а) номер пакета для получения пакетов в порядке их отправления и возможности сборки отправленных данных; б) целостность пакетов и отсутствие в них ошибок; в) номера портов получателя и отправителя (чтобы несколько программ на одной машине могли обмениваться данными); г) флажки для обслуживания TCP-соединения. Вся суть TCP сводится к предоставлению вам, т.е. прикладному уровню, некоего надежного виртуального "провода", которым вы как бы подключили одну программу на одной машине к другой программе на другой машине. В терминах типов коммутации, TCP поверх IP - это коммутация каналов поверх коммутации пакетов.
2) После сборки каждого сегмента TCP использует уровень IP как сервис, и отдает ему сегменты для упаковки в пакеты. Уровень IP нужен для предоставления возможности закинуть (т.е. маршутизировать) любой пакет с текущего узла на любой другой в сети. IP не предоставляет никаких гарантий о порядке прихода пакетов на узел, и даже о том, что они вообще придут (IPv6 также не проверяет целостность пакета), однако с его помощью сетевое оборудование в состоянии выбирать различные (!) пути для доставки пакетов получателю и осуществлять эту доставку. В заголовке IP-пакета, как на письме, указан узел-отправитель и узел-получатель.
После сборки пакета оный отправляется на канальный уровень для доставки по конкретной физической среде.

Теперь представим, если бы этих уровней (TCP/IP) не было. Самое простое, работающее по такой схеме, что приходит на ум - передача данных по COM-порту между двумя машинами. В такой схеме вы, вероятно, получали бы данные в порядке их отправления и возможно даже имели бы контроль ошибок, НО:
а) только одно приложение могло бы передавать/получать данные, т.к. нет виртуальных соединений (нет мультиплексирования);
б) для передачи данных машины нужно соединять физически. Ну или сажать тётеньку, которая бы перетыкала провода, как на первых телефонных станциях с ручной коммутацией каналов.
IP избавляет вас от пункта б), TCP - от пункта а) и тех доп. проблем, которые добавляет IP своим присутствием.

<TreeView ItemsSource="{Binding СвойствоОбщейВьюМоделиСодержащееКоллекциюЗаписей}">
    <TreeView.ItemTemplate>
        <HierarchicalDataTemplate ItemsSource="{Binding СвойствоОбъектаСсылающеесяНаОбъектРодитель}" DataType="{x:Type local:КлассОбъекта}">
            <TreeViewItem Header="{Binding СвойствоВОбъектеСТекстомДляОтображенияВУзле}"/>
        </HierarchicalDataTemplate>
    </TreeView.ItemTemplate>
</TreeView>

Не забудьте добавить описание неймспейса local.

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

> почему там все так заморочено?
Вы бы говорили с точностью до наоборот, имея проект с около 10к файлов исходного кода, а в солюшене 70 проектов. Вы бы говорили "Спасибо, VS, хоть как-то помогла разобрать это все". Это проф. инструмент, к сожалению он не позиционирован для обучения. Это факт.

Для обучения берите удобный редактор (Sublime?) и вызывайте компилятор руками (из ком. строки). Много чего поймете полезного (придется, иначе не получится ничего). Как include-директории передавать и всякое такое. Как задолбаетесь это делать - напишите sh-ник/bat-ник. А вот только потом вы и поймете, зачем вам Студия, и что она может/не может облегчить.

Любой нормальный поддерживаемый язык сохраняет совместимость на уровне синтаксиса, если не указано иного. Лично я нигде не встречал, что в F# была поломана обратная совместимость, поэтому предположу, что все в порядке. Тем более там изменений было не так уж много, кардинальных не было вообще.

и почему здесь нет тега F# или F SHARP?

очевидно, не популярны вопросы по F#. Тут и по C# спрашивают не так часто, как можно подумать.

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D...

ru.stackoverflow.com/questions/41844/%D0%97%D0%B0%...

Во-первых вам нужно ОЧЕНЬ ЧЕТКО понять принципиальную разницу между терминами "WCF service" и "windows service", т.к. общего между ними немного. Первое это про веб-сервисы, второе - это тоже что и демоны в *nix-системах. Первое это про архитектуру распределенной системы, второе это про жизненный цикл программы (как, когда и кем запускается/останавливается).

Поэтому:
1) если разработка под Винду, и

"служба должна выполнять в фоне некоторые действия с бд"

то почитайте про Windows Service - на шарпе такие пишутся относительно просто. Это не единственный способ запустить процесс, который будет крутиться и сам что-то делать в базе, но он предпочтителен.
2) если взаимодействие с клиентом подразумевается не по самодельному протоколу, а например по HTTP, то вам срочно нужно ознакомиться с тем, что такое веб-сервисы/веб-API и какие они бывают. Если вы уже понимаете что это такое, то вам нужно выбрать способ реализации под Дотнетом.

Подскажите, это можно сделать в рамках одной службы или нет?

Если под службой понимается Windows-служба, то можно. Стоит ли - другой вопрос, зависит от тех действий, которые вы хотите выполнять в фоне, архитектуры БД и политики работы с ней.

Вы что, шутите так время вычисления засекать?) Вы же не на Электронике считаете, несколько итераций/рекурсивных вызовов выполнятся настолько быстро, что вы даже не заметите. Михаил пожалуй назвал вероятную причину такого поведения, но это не отменяет того, что вы плохо ставите эксперимент.

При замере производительности одни и те же вычисления нужно проводить много раз, например по 100 тысяч раз на каждый вариант, а то и по миллиону. Тогда вы получите более-менее внятный результат для сравнения, и не будете натыкаться на всякие тонкости работы CLR.

Архитектура - это про то, из каких элементов ("черных ящиков") собирается система/подсистема.
Алгоритмы - это про то, как наиболее низкоуровневые элементы ("черные ящики") и выполняемые ими функции реализованы с помощью последовательности действий.

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

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

Точное определение алгоритма можно найти в других источниках.