Thursday, 15 August 2013

visual studio - How to avoid Winforms designer errors caused by assembly version mismatch, using NuGet workflow -



visual studio - How to avoid Winforms designer errors caused by assembly version mismatch, using NuGet workflow -

at out company, utilize nuget version our internal libraries. every commit library triggers build server, churns out new nuget bundle , uploads our internal feed.

this works pretty us, run issue winforms designer, reject load form error message this:

die datei oder assembly "uilib, version=1.0.0.906, culture=neutral, publickeytoken=null" oder eine abhängigkeit davon wurde nicht gefunden. das scheme kann die angegebene datei nicht finden.

(roughly: file or assembly "uilib, version=1.0.0.906, culture=neutral, publickeytoken=null" or 1 of dependencies not found. scheme cannot find file.)

this designer issue though - application build without problem , run intended.

this problem, need valuable context create sense out of it. form i'm trying open part of application (let's phone call app), , contains usercontrol part of our product-specific ui library (productuilib). library in turn references our general-purpose ui library (uilib). however, application depends on uilib directly.

both uilib , productuilib provided through own nuget packages. so, simplified dependency graph this:

app ----> productuilib ----> uilib | ^ ------------------------------|

all long productuilib , app reference same version of uilib (say, 1.0.0.906). however, if modify uilib , update nuget dependencies in app, app , reference latest version of uilib (say, 1.0.0.932). productuilib built against older uilib, should fine because changes uilib backwards compatible, , don't have strong names libraries either. , in fact, building , running app works fine. designer broken affected form , shows error message mentioned above.

to solve issue have update productuilib's nuget packages in turn builds against latest uilib, , update app's dependencies 1 time more new productuilib. gets tedious though, more libraries , dependencies.

i tested in both vs 2010 , latest vs 2013, new 1 shows exact same behaviour.

do have suggestion how can avoid issue?

we managed solve problem changing our strategy using assemblyversion, assemblyfileversion , assemblyinformationalversion.

we automatically generate lastly part of our version numbers on every build, setting current svn revision number. generated version number (e.g. 1.0.0.906) used go both assemblyversion , assemblyfileversion.

the designer apparently takes issue mismatch of assemblyversion assemblies differing assemblyversions deemed incompatible. however, normal loading process assemblies without strong name doesn't mind mismatch, building , running programme works. designer bit more picky.

the solution utilize fixed value assemblyversion update on breaking changes. generated version number goes both assemblyfileversion , assemblyinformationalversion. lastly 1 of import because nuget fill .nuspec $version$ placeholder assemblyversion unless assemblyinformationalversion nowadays override it, , want generated version number used our nuget packages.

so in summary:

only update assemblyversion breaking changes use assemblyinformationalversion number should go nuget package

winforms visual-studio dependencies nuget designer

No comments:

Post a Comment