Where does the "Version" value come from in a dll's properties in Visual Studio?
Currently moving over to .net 8 from Framework and getting used to the VS idiosyncracies
I've managed to figure how to alter the FileVersion, PackageVersion and AssemblyVersion for a dll build (what, no VersionVersion?)
However, I need to be able to quickly see the version of this built dll when I use it in other projects. I import the dll and it's properties look like the attached. However, I've set it to version 1.1.0.0 in my original dll build.
Where the hell are "Specific Version" and "Version" coming from and why aren't they showing as "1.1.0.0" (they do on the dll file itself - see attached)
Here's what I tried in the original dlls project file:
29 Replies
What is that first screenshot coming from? Like what is it showing? Why does it matter?
OK - so stigzler.Utilities.Base.TestUI references stigzler.Winforms.Base.
The file properties screenie is for stigzler.Winforms.Base in the stigzler.Utilities.Base.TestUI\bin\Debug\net8.0-windows folder (and shows the correct Version numbers as built in the stigzler.Winforms.Base codebase).
The first screenshot is the properties panel for the reference for stigzler.Winforms.Base in stigzler.Utilities.Base.TestUI.
Reason it matters is because I'm doing a huge upgrade task with multi-layer dependencies, so would rather be able to check at a glance in VS what version of a dll it is using rather than having to go in and manually inspect each dll file.
why are you referencing dlls in the first place?
what? Sorry - I don't understand your question - projects reference dlls, right?
are you using a
or
?
if the former, why?
Oh, I see. I added it via the VS UI (Dependencies>AddProjectReference>Browse and then browse to the stigzler.Winforms.Base dll)
The relevant csproj seems to be (auto gen by VS):
you will want to add a reference to the actual project, not the dll
that is assuming the projects are in the same solution of course
Huh? If I go through the route above, I can only browse to "Component Files" (exe or dlls etc) - there is no facility to essentially refernce an external project
no - not in same solution
i would have to question why they're not in the same solution, but there are plenty of good reasons for that. if the projects are coupled enough, sharing the same solution might make sense.
in any case, you should be perfectly able to reference projects outside of the solution, though it's a bit uncommon. what a project reference allows is for changes in one project to appear in the other projects instantly without you having to rebuild.
referencing raw dlls isn't usually something i would recommend anyone do, though it is very convenient
a local nuget package source is more appropriate, but more work
because Winforms.Base is re-used across many different solutions/projects.
Yeah - aware of this, but looking for solution with 'raw' referencing rather than through nuget
guess it might be a job for SO
i still don't quite understand why checking the version of the dll matters. you only have one version present at that path at all times anyway
and you should surely be aware of what version you last built
thanks for your help - will post on SO
good luck :p
what you want doesn't appear to be possible
SpecificVersion is a bool specifying whether only one specific version of a reference should be allowed to be included
Version, then, is that specific version you only allow to be referenced
meaning it's not something that can be fetched from the reference, but is something you specify to ensure version safety
@stigzlerapols - was afk. But
Version property does populate in Framework applications, as per attachment. ImageListView is a locally built and referenced assembly. Think I'll just put all this down to MS going increasingly backwards as ever before it goes forwards....
Could you show the entry for that reference in the project file?
The only place I see a version number specified in that package is
<ProductVersion>. I assume you cloned this to edit it locally...?
If the same isn't working for SDK projects, then the reason is simply because Visual Studio never received correct support for it. I wouldn't view it as a regression
I suggest reporting an issue from within VS
Worth noting that this matters exclusively for VS, other editors might neither know nor care about a display like thisYeah - cheers ero - as I thought
If you can, rethink the way you reference external code. It very much feels unlike what's done normally today. Is this for enterprise code? Or is it all private stuff?
oh no - I'm a hobby coder - just for silly retro gaming apps + plugins
Hmm. Well, there's not too much I can suggest beyond that. I have a feeling you've adopted a few practices that aren't standard, which may be the cause of your problems
Without a doubt
I agree the inconsistency between netfw and net is a bit of an eyebrow raiser, but perhaps if you report it as a bug, someone from the VS support team can help you out
Have you checked that it isn't
<ProductVersion>?
Or, perhaps, where is the 13.8.2.4 coming from in that reference above?
As in, what property stores that identifier in the ImageListView project?Good idea - I'll give that a go at some point - thanks for all your help
In any case, consider switching to project references where possible
$close
If you have no further questions, please use /close to mark the forum thread as answered
That's the file version. Its a PE level value.
Set by FileVersion.
Otherwise I agree with everything else people told him.
i'll believe it if this guy says it!