|
|
|
Peter Gabriel Sledghammer.
|
|
|
|
|
|
Ha ha ha - what a story! Morbid negativity! 
|
|
|
|
|
|
|
I would have to go with Night Club’s “Show It To Me” which is designed to be used with VR glasses but even without them you can look around at different things.
|
|
|
|
|
|
|
|
I have a WinForm application and start to build it daily. I need to maintain the build number now.
Any tips to share on build number management?
diligent hands rule....
|
|
|
|
|
|
There is a VS2022 version as well: Automatic Versions 3 - Visual Studio Marketplace[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I tried this add-in yesterday. it works well for my case.
diligent hands rule....
|
|
|
|
|
Anything new I use GitVersion - preferably using "Mainline" mode. My pipeline is always checked in with the main code repository, so any changes to it also forces a version update. The pipeline could be as simple as a script or msbuild project if you do not need a build server and just release from your own computer.
Edit: It seems you do not even need a build script for .net framework (.NET core on the way) as it can hook into msbuild for those who are so inclined (no idea why you would be even for a single person project, but each to his own I guess). This will run without any VS plugin or similar as it is all handled by adding the nuget package.
modified 26-Aug-23 15:11pm.
|
|
|
|
|
To add to Mike's suggestion, there is a newer version which works with the changes MS made at VS 2022: Automatic Versions 3 - Visual Studio Marketplace[^] - I'm looking at installing it tomorrow as I was writing a tool to automate release versioning for myself when I had a moment ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
From what I could see, it modifies the assembly version in the files when it run?
So you would have to commit these files? Or leave them out of git and restore them manually if lost (assuming single build computer)?
I have that in an old tool pipeline I am too lazy to change, but I would definitely not go down that route ever again.
|
|
|
|
|
I'm not sure - I was going to have a close look tomorrow (I don't have VS on my Surface ATM) but the way I was going to do it was to write an app that ran in a prebuild step for release only (easy to do) that modified the release notes to "fix" the version number from debug to release then ran again as a post build step to modify the assembly.cs file ready for the next debug version. Doing it in a VS extension seems a cleaner solution - but I've never written any of those!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
My favorite IDEs, for my favorite language, all do this automatically under the project properties. Just major/minor versions would need to adjusted manually, but build numbers get increased each time a "build" operation is executed....
|
|
|
|
|
I use the build in mechanism to automatically generate the 3rd (version) and 4th (revision) parts of the build number. The 3rd value is the day of the build and the 4th value is a value representing the minutes within the day.
So in assemblyInfo.cs have:
[assembly: AssemblyVersion("4.1.*")]
I have the major and minor set to 4.1 but these can be set to any numbers.
To retrieve the full version number values use:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Reflection;
using System.Diagnostics;
using System.IO;
static int Main(string[] args)
{
Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location);
string version = fileVersionInfo.ProductVersion;
int majorNo = fileVersionInfo.FileMajorPart;
int minorNo = fileVersionInfo.FileMinorPart;
int buildNo = fileVersionInfo.ProductBuildPart;
int revisionNo = fileVersionInfo.ProductPrivatePart;
}
|
|
|
|
|
I don't, as a rule, trust anything in the "Cloud" - breeches are all too common for my tastes. But I also have to use the same tools on multiple platforms, and so finally bought into Office365. I can't afford the obscene prices MS charges for the standalone products on multiple devices. So I'm rethinking this OneDrive thing. Apparently I can't kill it, and everything from MS defaults to OneDrive as the first listed place to store data, so I probably should learn to use it. My question is, should I keep most storage local, and use OneDrive as a backup destination? Or should I use OneDrive as a main storage location and use my local drives for backup storage? Or should I do something else?
How do you use it?
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: How do you use it?
I don't.
I keep everything on my PC local.
My phone (Android) puts some stuff in a cloud, but documents and images I keep local on my phone and move them to my PC.
|
|
|
|
|
It is not one or the other. OneDrive always have a copy (and keeps some history, but check it is enough for you to warrent not having an extra backup). Remember any ransomware or accidental modification will be synched to OneDrive as well.
You can decide which files/folders you always keep local, and which ones are only downloaded "on demand". If the files are important I would have at least one computer with the files locally.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
