Visual Studio + ProjectMaker. Заготовка VS для работы с проектами ZP

  • Автор темы Автор темы Dmitriy Ka
  • Дата начала Дата начала

Dmitriy Ka

Client
Регистрация
03.05.2016
Сообщения
949
Реакции
734
Баллы
93
100956


Вступление
Всем привет, это моя первая статья для конкурса статей ZennoLab:-). Хочу поделиться с Вами своим опытом разработки шаблонов для ZennoPoster, а именно рассказать, как можно быстро писать код для шаблонов ZP через Visual Studio.
В этой статье Вы узнаете, как создать заготовку решения Visual Studio, которая будет работать с любым проектом ZP. Через нее Вы сможете писать новые шаблоны для ZP или дебажить уже готовые проекты ZP. Настраивается все очень быстро и легко, а писать код гораздо удобней, чем в ProjectMaker.

Для кого статья
Данная статья подойдет:
- для новичков, которые только осваивают C#:bc:. В Visual Studio гораздо удобней писать код и большинство ошибки которые допускают новички будут подсвечены еще при написание кода.
- для продвинутых пользователей ZennoLab8-), которые пишут свои шаблоны на C# в ProjectMaker. В VS более крутой дебагер, через который можно будет дебажить уже готовые проекты ZP или писать новые.

Что Нам понадобиться
ZennoPoster V7.3.2.0 +
Visual Studio 2019
Скачать: https://visualstudio.microsoft.com/ru/vs/community/
.Net Framework 4.6.2
Скачать: https://dotnet.microsoft.com/en-us/download/visual-studio-sdks

Важно если у Вас Visual Studio 2020, то версия ZennoPoster должна быть 7.7.1.0 +

Подробная информации о кубике “Проект Visual Studio” можно прочитать в справке
ССЫЛКА: https://zennolab.atlassian.net/wiki/spaces/RU/pages/1375109121/Visual+Studio
Но на самом деле 80% информации, которая написана в справке нам не нужна!

Начинаем
Для быстрого создания решения Visual Studio которое будет работать с ZP, понадобиться кубик “Проект Visual Studio” в этом кубике понадобиться одна функция – Создать новый проект Visual Studio. Эта функция создает готовое решение в VS, которое сразу позволяет работать с ZP (в VS добавляются нужные ссылки ZP и создается метод для работы с ZP)

Кубик
100957

Создать новый проект Visual Studio
100958

Сохраняем решение VS.
Прописываем свои имена которые удобно и указываем путь где будет создано решение VS.

100959

Получаем Решение VS
100960

Запускаем уже созданное решение VS
Заходим в папку, куда сохраняли решение и запускаем файл .sln
100961

Важная информация!
При создание решения VS через кубик ZP, оно не привязывается к текущему проекту ZP в котором было создано! Это значит, что после создания решение VS, Вы можете работать с любым проектом ZP который будет работать в ProjectMaker. Еще раз подробней расскажу об этом в видео к данной статье.

Заготовка Visual Studio метод Execute
В Program.cs есть готовый метод Execute в который переданы объекты ZP instance и project. В нем мы и будем работать. Все что мы пишем внутри этого метода равнозначно тому, что мы бы писали в ZP внутри кубика C#, а все что пишется вне метода Execute равнозначно общему коду в ZP.

Так как мы создаем общую заготовку VS, через которую будем работать со многими проектами ZP, предлагаю немного упростить код в методе Execute и убрать все лишнее и оставить только return 0;

C#:
Развернуть Свернуть Копировать
public int Execute(Instance instance, IZennoPosterProjectModel project)
{


    return 0;
}

Что такое return 0 - метод Execute возвращает тип данных int, если возвращается 0 это равнозначно выходу по зеленой ветки в ZP в кубике С#, если вернуть любое другое значение - это выход по красной ветке, но так как эта заготовка под все проекты, сделаем выход всегда по зеленой ветке, потому что нам будет без разнице по какой ветке будет отрабатывать код, мы будем его постоянно переписывать с нуля для конкретного кубика. Если сейчас не понятна мысль, нужно посмотреть видео.

Решение Visual Studio, как с ним работать.
Так как метод Execute у нас один, то есть как бы один кубик как в ZP кубик С#, то писать весь код в данном методе будет плохо. Код получится очень длинным, его будет сложно дебажить, а через месяц в нем будет еще трудней разобраться :be:. Поэтому кубики мы будем создавать в ZP, а код для этих кубиков будем писать в VS.

Если дебажим уже готовый проект ZP, в котором много кубиков C#, мы просто копируем код кубика который хотим продебажить и вставляем в VS. Запускаем проект в ZP, исполняем все кубики проекта которые находятся до нужного кубика который дебажим, а код нужного кубика исполняем в VS.

После первого прочтения скорей всего это звучит как-то сложно и запутанно, на самом деле все легко, главное понять как это работает. Поэтому я запишу видео пример, где наглядно покажу как это все работает:-)


 
Номер конкурса статей
  1. Восемнадцатый конкурс статей
Тема статьи
  1. Нестандартные хаки
Последнее редактирование модератором:
за освещение дебага через VS : +
за использование статичных методов в общем коде : жирный -
а вообще я так же использую VS, к сожалению множество багов в зенке, пока что не дают развернуться более широко. так и приходиться копировать код из кубиков в VS и обратно (facepalm)

а для простоты копирования, использую вот такую конструкцию

100984


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

100985
 
Таким способом сам код отлаживать легче, но много суеты когда много кубиков и кода в общем коде, нужно туда-сюда переносить код, а этот в целом замедляет работу. Надеюсь в новой версии сделают это более удобно.
 
  • Спасибо
Реакции: Dmitriy Ka
за использование статичных методов в общем коде : жирный -
Это был простой пример, чтобы показать как работать с VS и общим кодом, а в статике писать чуть проще и быстрей:-)
 
Это был простой пример, чтобы показать как работать с VS и общим кодом, а в статике писать чуть проще и быстрей:-)
для одного потока... да... в многопотоке это вызовет кучу проблем... и они не вот так сразу явно выявляются. раз статья для новичков, то было бы очень хорошо этот момент четко обозначить.
ведь кубики и свой код в зенке потокобезопасны, об этом позаботились разработчики зенно, а вот общий код, потоконебезопасен , и там юзер может творить что угодно и безконтрольно.
поэтому пример бы обозначить как потоконебезопасный.
 
Теперь осталось новичку (как мне например) по зенопостер выучить C# :D
 
  • Спасибо
Реакции: Dmitriy Ka
Спасибо, статья для новичков в Сишарпе прям огонь! Вроде мелочь и скорее всего для людей в теме очевидная, а правильное направление задает!
 
  • Спасибо
Реакции: Dmitriy Ka и boragud
Теперь осталось новичку (как мне например) по зенопостер выучить C# :D
На самом деле там не так все сложно и страшно, если не погружаться в ООП:ap:
Есть мысль попробовать позапускать стримы для новичков, где показывать основные моменты, как передавать переменные ZP, как выводить информацию в лог и все такое))

Создал группу ТГ с анонсами стримов https://t.me/streamzp (Администрация, если это запрещено писать тут, то удалите пожалуйста, но вроде народ просит стримов :-) )
Если наберется человек 20+ то есть смысл пробовать что-то запускать
 
Последнее редактирование:
  • Спасибо
Реакции: Dmitriy Ka
Справка в статьях. За что голосовать то)
Поддерживаю, стать на два клика мышкой.
Создай кубик, подключи VS.
Всё как в справке, а ой в справке даже про возможные ошибки написано, а тут нет. :dz:
 
Справка в статьях. За что голосовать то)
Поддерживаю, стать на два клика мышкой.
Создай кубик, подключи VS.
Всё как в справке, а ой в справке даже про возможные ошибки написано, а тут нет. :dz:
Статью писал опираясь на свой опыт новичка. Новичку многое не понятно что написано в справке: там нет примеров, который помогли бы понять как это все работает. Я изучал этот кубик методом тыка, потому что ответов на вопросы, которые у меня возникали я не нашел. Это уже потом когда у меня стало чуть больше опыта и понимания C#, я понял как все это работает и о чем пишется в справке.
 
  • Спасибо
Реакции: userx и fridayman
отличная подача, почерпнул много моментов
 
  • Спасибо
Реакции: Dmitriy Ka
как так получалось, что добавляя переменные в project maker, их значение сразу было доступно в VS? Это так званый Dependency Injection?
 
как так получалось, что добавляя переменные в project maker, их значение сразу было доступно в VS? Это так званый Dependency Injection?
Не могу ответить на этот вопрос. Знаю что мы реализуем интерфейс IZennoExternalCode, в котором есть метод Execute, в который мы передаем instance (отвечает за работу браузера ZP) и project(отвечает за взаимодействие с проектом ZP: логи, переменные, профили и все такое) и так же в решение VS добавлены ссылки на библиотеке ZP, все это вместе позволяет так работать :-)
 
Статью писал опираясь на свой опыт новичка.
Я скорее всего являюсь новичком в данном вопросе. Прояснил любопытные моменты для меня.

Но мне бы хотелось реализовать, все следующим образом:
1. Распределить обрабатываемую информацию на сущности. Т.е. сущность отдельный класс и свои методы. Такой "своеобразный общий код" многофайловый получается. Я думаю при такой организации мне будет легче ориентироваться в коде.
2. Логику операций с методами сущности хочу положить в кубики - так проще дебажить и отслеживать, что получается в итоге.
3. Потом я хочу чтобы не захламлять => каждый класс в отдельные файлы положить (см. 1 пункт).
4. Потом очень хочется реализовать полиморфизм. Например есть общий класс назовем его "Класс-запрос-общий", а есть класс профильный запрос по смыслу, назовем его "Класс запрос сообщений". Из класса запрос профильный ("Класс запрос сообщений"), я хочу через полиморфизм запускать методы общего так скажем класса ("Класс-запрос-общий"). - чтобы опять же не хламить методы, не повторять. Т.е. по факту я хочу из простых методов лепить специализированные при этом.
Например метод: "ожидания подгрузки элемента" - он есть при каждом взятии HtmlElement, соответственно зачем мне везде циклы писать, я один общий цикл напишу: сперва топорно с одинаковым интервалом запроса (проверки на is.Void), а потом на более умный перепишу - например со сдвигом интервала (по моим правилам). И для реализации "переписывания" общего метода ожидания элемента мне не будет смысла переписывать все методы, я перепишу один - а все остальные его подхватят (по смыслу конечно).
5. Имеется ли какая-либо возможность перемещать данные из кубика в кубик без project.Context ? Вот с использование такого общего кода?

Просто общий код сложно дебажить - он простой партянкой вниз идет. По классам ориентироваться в такой ситуации несподручно.

А так конечно VS хорошо работает. Я не знал, что можно переключать браузер обратно в мейкер.

Может быть, если не сильно сложно сможете расписать такую реализацию? Для всех новичков будет полезно.

Моих знаний для такого не достаточно. Я думаю раз Вы претендуете на авторство в данном разделе - значит относитесь к более опытным пользователям. А у нас же комьюнити. Вот срез новичков за Вас и проголосует.
 
  • Спасибо
Реакции: Dmitriy Ka
1. Распределить обрабатываемую информацию на сущности. Т.е. сущность отдельный класс и свои методы. Такой "своеобразный общий код" многофайловый получается. Я думаю при такой организации мне будет легче ориентироваться в коде.
2. Логику операций с методами сущности хочу положить в кубики - так проще дебажить и отслеживать, что получается в итоге.
3. Потом я хочу чтобы не захламлять => каждый класс в отдельные файлы положить (см. 1 пункт).
4. Потом очень хочется реализовать полиморфизм. Например есть общий класс назовем его "Класс-запрос-общий", а есть класс профильный запрос по смыслу, назовем его "Класс запрос сообщений". Из класса запрос профильный ("Класс запрос сообщений"), я хочу через полиморфизм запускать методы общего так скажем класса ("Класс-запрос-общий"). - чтобы опять же не хламить методы, не повторять. Т.е. по факту я хочу из простых методов лепить специализированные при этом.
Например метод: "ожидания подгрузки элемента" - он есть при каждом взятии HtmlElement, соответственно зачем мне везде циклы писать, я один общий цикл напишу: сперва топорно с одинаковым интервалом запроса (проверки на is.Void), а потом на более умный перепишу - например со сдвигом интервала (по моим правилам). И для реализации "переписывания" общего метода ожидания элемента мне не будет смысла переписывать все методы, я перепишу один - а все остальные его подхватят (по смыслу конечно).
5. Имеется ли какая-либо возможность перемещать данные из кубика в кубик без project.Context ? Вот с использование такого общего кода?
Это все делается, мы создаем свою библиотеку через заготовку VS.
- То есть создаем свои классы и методы, потом через сборку собираем решение(свою библиотеку)
- В папке где храниться наше решение заходим в папку bin->Debug и копируем нашу библиотеку (.dll).
- Как добавить библиотеку в ZP ссылка (начало читать не обязательно, это все за нас выполнит кубик “Проект Visual Studio”), а как подключить библиотеку к ZP там хорошо написано.

Вот пример моей первой работы ссылка, там конечно говнокод написан:D, но примерный принцип понять можно), а по хорошему надо записать видео, так быстрей объяснить получится.
 
Ну вот и по технической части есть что почитать, спасибо. У меня при каждой попытке работы со студией через зенку, всегда какие то ошибки сыпались, и лень было разбираться и тратить время, а теперь может очередной заход что то изменит. А если нет, то буду по привычке отдельно в студии работать (в ней удобнее отладку делать) и переносить готовый код в зенку.
 
  • Спасибо
Реакции: Dmitriy Ka
Статья про новые полезные знания и опыт специалиста - актуально! :-)
 
  • Спасибо
Реакции: Dmitriy Ka
Я пишу полностью в VS и потом переношу в 1 кубик, когда больше одного это не очень удобно

Еще очень удобно методы свои делать для оптимизации кода, но это уже немного о другом
 
Я пишу полностью в VS и потом переношу в 1 кубик, когда больше одного это не очень удобно

Еще очень удобно методы свои делать для оптимизации кода, но это уже немного о другом
а помоему это как раз в тему....
конечно копировать туда-сюда не очень удобно и занимает много времени. поэтому делать и отлаживать библиотеку в VS , самое логичное. а в кубиках C# использовать только отлаженные функции из этой библиотеки.
плюсов дофига. правка бага в функции, влияет сразу на все кубики в проекте. не надо 100500 кубиков править.
библиотеку легко перенести в другой проект. не надо искать по 100500 кубикам нужный код.
навигация по библиотеке в VS намного лучше, чем в портянке общего кода зенки. удобненькие вкладочки :D

101060
 
а помоему это как раз в тему....
конечно копировать туда-сюда не очень удобно и занимает много времени. поэтому делать и отлаживать библиотеку в VS , самое логичное. а в кубиках C# использовать только отлаженные функции из этой библиотеки.
плюсов дофига. правка бага в функции, влияет сразу на все кубики в проекте. не надо 100500 кубиков править.
библиотеку легко перенести в другой проект. не надо искать по 100500 кубикам нужный код.
навигация по библиотеке в VS намного лучше, чем в портянке общего кода зенки. удобненькие вкладочки :D

Посмотреть вложение 101060
Да, я просто не сразу понял твое сообщение. Мне не нравится идея ТС делать кучу кубиков и отдельно дебажить. Как по мне это очень не удобно.

А дебажить мне кажется лучше сразу в VS. Там в принципе все намного удобнее.
 
Последнее редактирование:
Да, я просто не сразу понял твое сообщение. Мне не нравится идея ТС делать кучу кубиков и отдельно дебажить. Как по мне это очень не удобно.
Цель статьи была показать, как можно работать с проектами через VS, а не как писать код.

Мысль по поводу делать кучу кубиков. Я читаю форум и иногда вижу людей, которые говорят что у них есть кубики с кодом на 2к строк. Работать с таким кубиком очень сложно, лучше будет разбить его на 10-15 кубиков, тогда с проектом работать будет гораздо проще. Это по типу один метод - одно действие, такой смысл закладывался.

А вообще конечно лучше создавать свою библиотеку под проект или проекты, а не писать весь код в кубиках и общем коде.
 
  • Спасибо
Реакции: lamar015
а не писать весь код в кубиках и общем коде
Какой смысл тогда в VS?

Все что внутри метода public int Execute(Instance instance, IZennoPosterProjectModel project) {return 0;} - это кубик, так?
Если я еще создам файл Сlass.cs - это будет общий код?
 
Какой смысл тогда в VS?

Все что внутри метода public int Execute(Instance instance, IZennoPosterProjectModel project) {return 0;} - это кубик, так?
Если я еще создам файл Сlass.cs - это будет общий код?
да.
в VS это отдельный файл и отдельный Сlass, логически связанный в проекте с помощью namespace или using или вообще не связан и обращение к нему идет по полному указанию пути
но в зенке, нет отдельных файлов, поэтому все namespace , using и классы абсолютно все помещается в общий код друг за другом, как одна большая портянка.

101069
 
  • Спасибо
Реакции: afk
Какой смысл тогда в VS?

Все что внутри метода public int Execute(Instance instance, IZennoPosterProjectModel project) {return 0;} - это кубик, так?
Если я еще создам файл Сlass.cs - это будет общий код?
В VS мы можем написать свою библиотеку классов, потом эту библиотеку подключить к ZP (как это делается написал выше) и нам уже не надо писать портянку в общий код, кубики будут работать через подключенную библиотеку.

Фраза "не писать весь код в кубиках и общем коде" - значит написать свою библиотеку и через кубики с ней работать. Просто некоторые (да я и сам в начале) вообще не используют общий код или библиотеку и пишут все в кубиках, а написание своих библиотек уменьшают объем написания кода в кубиках ZP(надеюсь понятно выразился :-) )
 
Спасибо за хороший материал. Пока на связку ZennoPoster и Visual Studio не перешел, но, надеюсь, что Ваша статья поможет мне в этом :ay:
 
  • Спасибо
Реакции: Dmitriy Ka
Добавлено ещё одно видео от автора в конец первого поста.
Тема видео: Как написать свою библиотеку для Visual Studio и подключить её к ZennoPoster
 
  • Спасибо
Реакции: Dmitriy Ka и djaga
Спасибо за статью! Буду изучать и голосовать...
 
  • Спасибо
Реакции: Dmitriy Ka

Кто просматривает тему: (Всего: 0, Пользователи: 0, Гости: 0)