Як усім відомо, .net-програми генерують .dll файли в папці bin після їх генерації, але звідки походить файл .dll.refresh? Того дня я загуглив інформацію про нудьгу і дізнався, що це автоматично генерується при посиланні на сторонню асемблю (direct) у вашому проєкті, цей файл .refresh зберігає оригінальний шлях до цього стороннього файлу, якщо dll за цим шляхом оновлюється, а не при створенні проєкту, асемблер оновлюється і змінюється відповідно до цієї адреси. Без цього файлу VS не зможе оновити згаданий асемблер відповідно до останнього статусу, що призведе до проблеми неправильної версії асемблера. Дрібниця призведе до великої проблеми, всі зверніть увагу!
Була випущена нова версія сайту, і було виявлено серйозну проблему: одна з бібліотек не оновлювалася автоматично, а застаріла версія генерувалася автоматично.
Після розслідування виявилося, що це пов'язано з файлом dll.refresh у VSS.
Причина проста:
1。 Під час розробки, коли на вебсайт додаються інші зовнішні посилання на DLL, система автоматично генерує файл оновлення, і цей файл не буде згенерований, якщо за цим рішенням додаються інші посилання на DLL проєкту
2。 Файл оновлення вказує шлях для автоматичного оновлення dll, і якщо це посилання на бібліотеку, він вказує каталог Dubug або Release, а цього разу файл, який виходить з помилкою, — це каталог Debug
3。 Розробник помилково перевірив файл у коді VSS
4。 Проблема в тому, що бібліотека посилань змінювалася багато разів після випуску першої версії, але інтерфейс не змінювався, тому бібліотека генерується окремо, і тоді оновлюється лише відповідна DLL (версія випуску) усіх додатків, і проблем не виникало, але коли додаток повторно публікується через наявність файлу оновлення в каталозі BIN проєкту, DLL автоматично оновлюється шляхом, вказаним файлом, що призводить до випуску старої версії DLL (Debug версія).
Вирішення проблем:
Видаліть файл dll.refresh у додатку і опублікуйте його знову
Або змінити вміст у dll.refresh і правильно записати шлях до dll
|