Main Site Documentation

Assembly reference version guidance


#1

I just upgraded my FEZ Domino to the 4.1.5.0 code (I was using the 4.1.3.0 code). This broke my assembly references for some of the GHI assemblies.

What’s the right way to handle this? If you look at the diff at https://github.com/bcr/NetmfAndroidOpenAccessory/commit/f21d8f1f3d498d8b7e1d7f45ea65f20cc0ccfca9 you can see that it’s just:

I know my code works with the 4.1.3.0 code, and I know that there is generally a concept in .NET of “as long as the version is kinda the same, use that assembly”. For GHI assemblies what is the right guarantee of API compatibility? That is, can I just say Version=4.1.* and be done with it?


#2

Simply remove all assemblies from your project then add them back.


#3

Yes, this is what I did (as per the diff).

I thought there was a more compatible way to do it than “everyone who uses my code better have the same versions of the assemblies, even though I don’t use features in the newer versions.”

That is, anyone who gets my code that doesn’t have 4.1.5.0 (let’s say they have 4.1.3.0) has to update their GHI code/firmware (which is probably a good idea anyway) or delete and re-add the references in my library csproj to refer to their older 4.1.3.0 version, even though I don’t use any features specific to 4.1.5.0, and 4.1.3.0 would work fine.


#4

If you don’t include the GHI assemblies files in your project (output folder), I think Visual Studio will automatically get them from GHI SDK.
Delete the output folder before trying the project on another computer or SDK. It should work…


#5

In VS2010, if you right click on your project and click Clean, VS will empty the output folder (both debug and release).


#6

It works for me to use:

instead of

The IDE resolves the right version, but I’m not sure how this would work if there were multiple frameworks installed, but I don’t think that’s the case with most people.