Pull to refresh
0
0
Антон @whirl

C# Programmer

Send message

Первый шаг по превращению мешков с костями людей в батарейки!

Или конкректно с графами и диаграмами показывать почему GC без ручного решения задачи управления взаимосвязями не способен обеспечить работу взаимосвязей по правилам ООП.

Давайте, было бы интересно увидеть.
Речь не шла о том плох или хорош WCF а о целесообразности его использования в наше время.

Внутри корпоративного сектора есть задачи где использовать его вполне себе рационально. Просто потому что у него есть свои плюшки в виде поддержки кучи транспортов, типов сериализации, авторизации и прочее.

Например в .netcore максимум что вы можете сделать, так это сгенерировать WCF клиент.

И даже при этом далеко не все в нем поддерживается, но для того чтобы запилить полную поддержку — нужно громадное количество кода.

WCF изрядно громоздкий и не отвечает потребностям современного рынка, да и существует он только в мире .NET и то не в core.

Да, он громоздкий, но вот по поводу потребности — не согласен. Тут надо понимать что WCF — это SOAP, который описывается через wsdl. И в net core вы можете сгенерировать клиента к любому SOAP сервису не только WCF. Не обижайте клуб любителей java с их спрингом и прочими плюшками. Нельзя просто так взять и похоронить хороший протокол (по крайней мере для корпоративного сектора).
Какое то у вас слишком категоричное мышление. А вы не думали, что у каждой технологии есть как преимущества, так и недостатки. Я так понимаю, что в SOAP вы видите одни недостатки. Но их и в REST порядком. Это если не привязываться к .Net в принципе. Да, для многих вещей, особенно публичных REST и .NET Standard отлично подходят, но есть и много других — для которых SOAP и WCF вполне себе хорошее решение.

PS Я вполне себе представляю как недостатки WCF так и преимущества (по крайней мере для меня), то же самое относится и к REST. Но ваш ответ выглядит весьма хамским.
Честно говоря мне тоже непонятен чем плох WCF. А на вопрос вы так и не ответили.
Я к тому, что перед применением конфигурации вам обычный publish сделает еще и сборку проекта и еще много других ненужных вам вещей. А хочется, чтобы один проект, который собирается под CI и пакуется потом в артефакты можно было задеплоить на любую среду окружения будь то prod/qa/dev без повторной компиляции проекта. Поэтому и говорю что трансформацию конфигурации лучше держать подальше от процесса сборки. Если брать тот же .Net Core, даже трансформации не применяются все конфиги накатываются скопом, а потом в зависимости от окружения берутся подходящие значения либо из базового конфига, либо из конфига окружения. Что не исключает возможность их получения из других источников подробнее тут

Замечу только, что есть техники, позволяющие шифровать куски web.config'а.

Сталкивался я с такими техниками, больше не хочется.
Таки как вариант ansible. Очевидно, что задавать надо там, где делаете оркестрацию сервисов
Эммм оверхед приличный, особенно когда у всех разработчиков конфиги начинают разъезжаться
А как вы все это собираете? Вы добавили в проект несколько конфигураций сборки. В данном случае у вас конкретная трансформация применяется в момент сборки проекта, но это же очевидно плохое решение. Конечный вид конфигурации должен зависеть от того в каком окружении запускается приложение, либо вобще от него не зависеть.
В вашем случае имхо трансформация конфига должна применяться не в момент сборки, а в момент публикации.
Так же непонятно как вы в своем решении прячете продакшн конфиг, в котором могут содержаться боевые логины/пароли и т.д. если все это зашито в релизную трансформацию, то это тоже решение не очень.

Как выше заметили для решения таких проблем используются либо переменные окружением, либо сервисы которые в зависимости от 1 переменной окружения (dev|stage|prod) выдаст вам актуальную конфигурацию для приложения

по поводу LogEvent недавно прикрутили в нлог structured logging, хотя я все равно поклонник Serilogа
Потому что его относительно легко подобрать при перехвате достаточно большого количества сообщений и расшифровывать все подряд. В данном варианте у каждой сессии будет свой ключ для блочного шифрования. Подобрав SIGNATURE_KEY можно будет расшифровать публичный ключ которым обмениваются сервера, а потом еще ведь необходимо как то расшифровать содержимое. В общем задача по дешифровке усложнится во много много раз
Ну для сторонников Intellij Idea для разработки на .Net есть Rider

Но это конечно восхитительно в качестве среды разработки под .Net использовать IDE написанную на Java
Мы писали-писали на .Net-стеке с MS SQL Server, а потом ВНЕЗАПНО осознали, что нам нужен LAMP

Увы, так бывает, к примеру на одной из предыдущих работ внезапно захотели хранить кредитные карты пользователей, что влечет за собой сертификацию по PCI DSS и отдельную изолированную базу данных.
Т.к. все писали на Net-стеке с MS SQL Server то и выбор был соответствующий. Но к моменту релиза внезапно! оказалось, что лицензий нет и необходимо переехать на PostgreSQL. И вот черт его знает баловство это или нет =(
Во-вторых, должны использоваться открытые алгоритмы и технологии, а не кривое только-под-винду-Xp проприетарное ПО.

Ну мы же в России живем. Это же крипто про, какие открытые алгоритмы и технологии?

Не забудьте, что номер каждого токена должен быть вписан в пасспорт чтобы все знали кто есть кто
Ошибся кнопкой, писал ответ на комментарий выше.
А разве решарпер работает с Express версией студии?
Если сильно хочется, то можно взять и синезубую мышку
Есть несколько воронок:
1 Налоги (на продажу товаров и производство)
2 Разница между выплачиваемой страховкой и стоимостью корабля (особенно учитывая что страховка платится только за корабль, а не за установленные в него модули стоимость которых может быть намного больше стоимости корабля)
3 Оплата прав собственности на систему 3
4 Оплата некоторых модулей устанавливаемых на POSах (Player Owned Structures) таких как циножаба (не позволяет вражеским кораблям запрыгивать в систему по циномаяку)
5. Оплата производственных линий
6 Оплата улучшений клонов
За сбитые корабли выплачивается страховка(стоимость корабля покрывает не полностью), модули установленные на корабли сгорают с вероятностью 50%

Information

Rating
Does not participate
Location
Королев, Москва и Московская обл., Россия
Date of birth
Registered
Activity