Почему FileSystemWatcher не обнаруживает изменения из Visual Studio?
Хорошо. Наконец-то я начал работать:
Я полностью удалил параметр из родительского конвейера. В дочернем конвейере (который называется HubMaster) мы создаем параметр с именем MasterBatchId:
В родительском конвейере я создал [114 ] Выполнить узел конвейера с именем EP_HubMaster, который вызывает дочерний конвейер с именем HubMaster. Чтобы заполнить дочерний параметр конвейера MasterBatchId во время выполнения, нам нужно отредактировать JSON родительского конвейера, чтобы он выглядел следующим образом:
{
"name": "TestParent",
"properties": {
"activities": [
{
"name": "EP_HubMaster",
"type": "ExecutePipeline",
"typeProperties": {
"pipeline": {
"referenceName": "HubMaster",
"type": "PipelineReference"
},
"parameters": {
"MasterBatchId": {
"value": "@pipeline().RunId",
"type": "Expression"
}
}
}
}
],
"folder": {
"name": "Master"
}
},
"type": "Microsoft.DataFactory/factories/pipelines"
}
Вы можете видеть, что мы передаем @pipeline().RunId от родительского (что было первоначальным намерением) для входного параметра MasterBatchId в дочернем конвейере.
2 ответа
Это было действительно умом, пугающимся..., когда Вы попробуете мой пример программы ниже и изменяете файл в VS, Вы заметите две строки в своем окне вывода:
Удаленный
Переименованный
Таким образом, Visual Studio никогда не изменяет существующий файл, она сохраняет константы в новый файл с временным именем, затем удаляет исходный файл и переименовывает новый файл к старому названию.
На самом деле это - хорошая практика, потому что, если бы Вы делаете это обычный путь (просто пишущий измененный файл, который вызвал бы Changed событие, которое будет запущено), обработчик событий можно назвать, прежде чем запись завершена. Если бы обработчик событий обрабатывает содержание файла, это может вызвать проблемы, потому что он обработал бы неполный файл.
Другими словами: это не ошибка, это - функция ;-)
static class Program
{
[STAThread]
static void Main()
{
FileSystemWatcher FSW = new FileSystemWatcher("c:\\", "*.cs");
FswHandler Handler = new FswHandler();
FSW.Changed += Handler.OnEvent;
FSW.Created += Handler.OnEvent;
FSW.Deleted += Handler.OnEvent;
FSW.Renamed += Handler.OnEvent;
FSW.EnableRaisingEvents = true;
System.Threading.Thread.Sleep(555000);
// change the file manually to see which events are fired
FSW.EnableRaisingEvents = false;
}
}
public class FswHandler
{
public void OnEvent(Object source, FileSystemEventArgs Args)
{
Console.Out.WriteLine(Args.ChangeType.ToString());
}
}
}
Только зарегистрировать эту возможность...
Из MSDN:
Если несколько объектов FileSystemWatcher будут наблюдать тот же путь UNC в Windows XP до Пакета обновления 1, или Windows 2000 SP2 или ранее, то только один из объектов сгенерирует событие. На машинах, выполняющих Windows XP SP1 и более новые, Windows 2000 SP3 или более новый или Windows Server 2003, все объекты FileSystemWatcher сгенерируют соответствующие события.
Таким образом, моя идея состояла в том, что Visual Studio содержит свой собственный FileSystemWatcher на файле по любой причине... однако Вы не имеете никаких путей UNC и не упомянули ОС.