I need to get full windows version, i.e. major, minor, build number and revison, so for example: 10.0.22000.1455 using golang app.
I tried using wmi - Win32_OperatingSystem class. Problem with this one is that it does not include revision, so what I get is, for example: 10.0.22000
Other way I tried was calling ver command and extracting version from the response, which works fine, but does not work for windows server 2016 and lower. Simmilar issue as above
Any ideas for solution/workaround?
Related
Is there a way to give users a link to the latest version of Windows Terminal msixbundle?
Or even how to get the URL programmatically?
Like pseudo code:
location=curl -sI https://github.com/microsoft/terminal/releases/latest | grep location:
version := path.Base(location)
versionNoV := version[1:]
wtfisthis := "8wekyb3d8bbwe"
base_url = "https://github.com/microsoft/terminal/releases/download"
url = fmt.Sprintf("%s/%s/Microsoft.WindowsTerminal_%s_%s.msixbundle",
base_url, version, versionNoV, wtfisthis)
GitHub doesn't provide an automatic link for the latest release that can be used to directly download a release asset. In general, you should be careful about trying to do this, since sometimes the latest release is a new major version, bringing in incompatible changes.
However, you can query the GitHub REST API to find assets related to the latest release. That will contain the proper URLs to use. However, it is not static.
Normally, this is possible for GitHub releases if the released binary has a static filename.
So, for other projects you can simply download the latest release with a fixed URL like: https://github.com/ytdl-org/youtube-dl/releases/latest/download/youtube-dl.exe. Unfortunately, that will not work with the current release process for Windows Terminal.
Reference: https://docs.github.com/en/repositories/releasing-projects-on-github/linking-to-releases
Several people have contributed short scripts to help address this here: https://gist.github.com/steinwaywhw/a4cd19cda655b8249d908261a62687f8
I've been practicing updating Indy on a VM and I've gotten far enough to compile some of my projects but not all.
First of all I'm Delphi Seattle, updated to Indy 10.6.2 following the instructions here
In my client projects that use Indy, there is IPPeerClient in the Uses clause. This is causing the error "Unit IPPeerClient was compiled with a different version of IdTCPConnection.TidTCPConnection". I can remove the Use statement and they seem to be working (so far, the ones I've tested).
But for my server projects (datasnap and others), if I try to remove IPPeerServer, it gets added back in automatically and I'm stuck.
I have these CLR types installed on my local https://puu.sh/yEWG5/b4f77fba7b.png
Also, I have SQL server 2016 installed on my local system but when I try to run the project I get error as below
https://puu.sh/yEWQm/78a4220830.png
Can someone help? I tried installing latest nugget package from https://www.nuget.org/packages/Microsoft.SqlServer.Types/ but it did not help.
Though I am able to add a column of type geography in a table in my local database. It fails at runtime when I run my project and error comes as below
https://puu.sh/yEWQm/78a4220830.png
According to the docs if you have installed the CLR Types it should load from the GAC so I'm not sure why that didn't work for you. (I would check that you have the correct version as your dependency)
However, we do use the SQLServerTypes in our app without installing the CLR types by using the following method (this method is described in the readme.htm that comes with SqlServerTypes).
Grab the SqlServerTypes.nupkg and extract it to a folder lets call this folder SST from now on.
(Locations of the files I talk about in the following steps may differ from version to version but, the principle is the same)
Create a SqlServerTypes folder in your project
Copy the SST/nativebinaries/x86 and x64 folders into your new SqlServerTypes folder
Also copy the files from SST/content (you should see Loader.cs and readme.htm) into the SqlServerTypes folder.
Now all you need to do is call the Loader when your app boots up.
We do this during our autofac setup by making this call.
Utilities.LoadNativeAssemblies(AppDomain.CurrentDomain.BaseDirectory)
You may need to adjust the param passed into this method to work with your application. If the correct path is used you should have access to the spatial types in your code.
edit: It may be possible to just call the LoadNativeAssemblies straight away (and avoid all the work I posted above) if you have installed the nuget package in your app but, I have not tested this as we are stuck on an old version of SqlServerTypes.
Because i cannot put a comment i have to put a answer, you can check that, that article and this, this, this and this answers, i hope they guide you to someting usefull.
I downloaded go1.4.darwin-amd64-osx10.8.tar.gz and extract it on my local directory.
Based on what Installing to a custom location says I added GOROOT in env variable.
Based on what Test your installation says I created a go file.
I finally ran it and I got expected result as following screenshot.
I actually have IntelliJ v.14 however, based on this article I installed Go Language (golang.org) version 0.9.15.3 in my IntelliJ Idea.
I created a Go project and during creation it asked me to add GO SDK. I gave it ~/Desktop/go/sdk however it wasn't able to recognise it. I got this error in Event Log:
14:03:02 IllegalArgumentException: Argument for #NotNull parameter
'virtualFile' of
com/intellij/openapi/projectRoots/impl/ProjectRootContainerImpl.addRoot
must not be null
Any idea how IntelliJ Idea is able to recognize it would be appreciated. Thanks.
Please consider using one of the alpha releases for 0.9.16. I believe that alpha7 could be the more stable one rather than alpha9. You can get them from GitHub releases
The v1.0.0-alpha0 branch is, as the name implies, an alpha release and it's in the early stages of development, that's why there's no release done yet for it as well.
P.S. I'm one of the contributors to the plugin.
Does not allow to use SDK placed in /usr/local/go (perfectly valid and recent SDK) under Mac Yosemite.
Google App Engine does not recognise last valid GAE GO SDK either.
~Desktop/go/sdk doesn't seems a valid path (as it refers to the homedir of the 'Desktop' user): ~/Desktop/go/sdk should work better.
As long as you see in that ~/Desktop/go/sdk folders the subfolders 'api', 'bin', 'blog', ..., that should be the right one for the GO SDK expected by the "golang support plugin".
Some issues exist with that plugin and IntelliJ 14: issues 1169, PR 1172 (fixed for for 1.0.0-alpha).
The other approach is to recompile and install that plugin.
The end result of specifying the Go SDK path should look like:
Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.