I have installed the Google Cloud SDK in Windows 7 as instructed in the Google Cloud SDK document. And its installed in C:\Program Files\Google\Cloud SDK.
But I haven't seen any option to completely uninstall this SDK in windows control panel.
On the latest SDK, Under "C:\Program Files (x86)\Google\Cloud SDK" you should find an uninstaller (uninstaller.exe). Just execute it.
I have also been struggling with this.
As far as I can tell, the Google App Engine SDK Windows installer installs a whole bunch of binaries into C:\Program Files\Google\Cloud SDK, installs Python 2 (2.7.6 as of this post's writing), creates a CLOUDSDK_PYTHON environment variable, and updates your PATH variable to reference the Python and Cloud SDK locations.
The Cloud SDK Core Command Line Tools (gcloud) can assist you with removing most of the binaries. It's been suggested elsewhere that these binaries can just be deleted, but I uninstalled them one-by-one, just to be safe. To do this (taken from L.H's post here), launch the Google Cloud SDK Shell from your Start menu, and run gcloud components list to see all the SDK components. Each can be removed by running gcloud components remove [COMPONENT_ID]. I removed all of the Individual Components before removing the Cloud SDK Core Command Line Tools Package.
Python includes an actual Windows uninstaller with its installation, you you can just remove it as normal via Add/Remove Programs.
Then, you can just Remove the Google Cloud SDK-related Environment Variables and the references in your PATH variable.
To get Cloud SDK Uninstalled manually on WINDOWS(7 for me) :
Delete following two folders from your windows machine:
Cloud SDK Installation folder
* mostly found at standard installation folder- C:\Program Files (x86)\Google *
or custom location if you chose one during installation
Cloud SDK configuration folder in case you configured it after installation
* Default location is user-level AppData\Roaming\gcloud *
C:\Users{USERNAME}\AppData\Roaming\gcloud
Apart from this, I found entry of (Google) Cloud SDK in CONTROL PANEL-->Uninstall Programs too. Use this option to uninstall as well. It may throw alert if already deleted.
Last but not least:
Check your system environment variable "PATH". Remove any path that points to Cloud SDK locations.
Hope this would help windows user :)
Related
I'm trying to forward events in Windows 10, I found a great github repo that seems to have all the subscription XML stuff in it that I need, but when I go to install the channels (read, logs) so that the subscriptions receive everything, it doesn't work because the custom channels aren't there...the github repo contains a dll that supposively contains the custom channels and a manifest file (.man) you can use to create it yourself (seems to have alot of XML in it).
I didn't really trust a .dll I download from a github repo in my environment, so I decided that since they tell you how to build the .dll. The github repo references a technet blog post, that tells you how to build the .dll, but it's a bit dated being from 2016 and all.
I installed the Windows 10 SDK to try this out, but it doesn't include the file they told me to run to build the .dll from the manifest, mainly C:\Program Files (x86)\Windows Kits\8.1\bin\x64\ecmangen.exe
I read in an unresolved unanswered post that the executable was removed in from the Windows 10 SDK starting with version 10.0.16299.15, and that the op decided to just use an older version.
Was this tool replaced with something else? I don't really want to use a DLL I found in a github repo.
ecmangen.exe removal from the SDK: Ecmangen.exe will no longer ship
with the Windows SDK. Developers who rely on ecmangen for event
manifest creation are advised to install the Windows Creators Edition
of the SDK to obtain the file. Developers may also use notepad or
other XML editor of choice for manifest creation. A schema file is
available on MSDN to aid in manifest creation, for tools that support
it.
Refer to "Windows 10 SDK Preview Build 16267 and Mobile Emulator Build 15240 Released".
Refer to here for Windows Creators Edition of the SDK.
You can find ecmangen.exe at the following path:
The manifest tool mt.exe is included in the Windows SDK. But the full SDK is large and includes a lot of things as shown in the screenshot. But which of these options actually includes mt.exe?
Ideally I'd like to install just the minimum to get this tool on the system.
It does say in the docs that mt "is available in the Microsoft Windows Software Development Kit (SDK)" - but thats it, without any further detail.
Choose Windows SDK for Desktop C++ x86 Apps.
Additionally, you can then grab the mt.exe binary and put it in a location of your choice, if you don't want to keep the rest of the stuff that comes with that option (say, on a build server). The mt.exe doesn't have any dependencies other than OS dlls.
If you have downloaded the ISO file of Windows SDK, grab the MSI called "Windows SDK for Windows Store Apps Tools-x86_en-us.msi" in the folder Installers
You can just extract (without installing) the content with an administrative installation:
msiexec /a "path_of_your_msi\Windows SDK for Windows Store Apps Tools-x86_en-us.msi" TARGETDIR="Full_Extract_Folder_Path" /qb
Then search mt.exe in your extract folder
Working with VS2017 Community I have written a service that works on my local machine. I followed the instruction here:
https://learn.microsoft.com/en-us/dotnet/framework/windows-services/walkthrough-creating-a-windows-service-application-in-the-component-designer
and installed it successfully using Installutil.exe (as per instructions in above link). All good.
I now want to deploy that across six servers in our organisation. In Microsoft's documentation about installing services (https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-install-and-uninstall-services) it says:
If you’re a developer who wants to release a Windows Service that users can install and uninstall you should use InstallShield
and links to a page that applies to VS2012 (can't post any more links as my reputation<10)
I have downloaded and installed the "Microsoft Visual Studio 2017 Installer Projects" package, which allows me to create a Setup Project. When I run it, it installs the project output correctly (i.e. copies the exe & dll files to the correct folder in Program Files) but does not create the service.
There's a detailed post about deploying services on this site (question 9021075) but when I follow those instructions I get a 1001 error on Install.
All the documentation I can find refers to earlier versions of VS or the previous Installer package, so I'm not even certain if I can do it with the software I am using.
So, with VS2017 Community using Microsoft Visual Studio 2017 Installer Projects, how to I create a stand-alone Installer to deploy a service that works correctly when installed locally using InstallUtil?
Or can I use InstallUtil on the target machines? I think I'd need to install Visual Studio on them for that, which I'd prefer not to. Is there a quicker way?
I only have 6 servers to install this on, so even some manual work-around might do.
Thank you for the responses. I now have a solution. I found InstallUtil on the Target Server (in my case it was in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 but search will find it). I copied and added that to my project as content so when I now deploy it, I have InstallUtil in the same folder as my EXE.
To install, I run CMD as admin, cd to project folder and issue command:
installutil.exe myService.exe
This is a one-off task. Once the service is working, to update it I just need to stop it, upload the new myService.exe (& any DLLs) to overwrite the old ones and restart it again.
Further information about settings you're using for the serviceProcessInstaller1 and serviceInstaller1 files will be needed to debug this issue, as the 1001 error raised by the installer is a generic error.
An alternative way of doing this is to use Topshelf, which is a framework for hosting services written using the .NET framework. It simplifies the creation of services, allowing developers to create a simple console application that can be installed as a service using Topshelf. The reason for this is simple: It is far easier to debug a console application than a service. And once the application is tested and ready for production, Topshelf makes it easy to install the application as a service.
Alternatively, you could use InstallUtil.exe. It is part of the .NET Framework, so no need to install Visual Studio.
I'm facing a typical Microsoft bug whereby I am unable to install Windows Azure Active Directory Module Found here Windows Azure AD for Powershell
Background:
I am Running Windows 7 with Service Pack 1.
Powershell 4.0 is currently installed.
Microsoft.Net Framework 3.5.1 is checked under programs and Features
Microsoft Online Services Sign-in Assistant Both Beta and non Beta versions were installed..PC rebooted and no luck with either of them.
I have read many posts online and none of them appeared to have helped.
Does anyone know how to overcome this annoying bug.
http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/09/error-when-trying-to-install-windows-azure-active-directory-module-for-windows-powershell.aspx
http://social.msdn.microsoft.com/Forums/windowsazure/en-US/aef5669a-bc46-4c7a-9cbd-d0ed781e5190/waad-wont-install-says-signin-assistant-needs-to-be-installed-but-it-already-is?forum=WindowsAzureAD
I finally found a solution to this from Erik who posted on this site.
http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/09/error-when-trying-to-install-windows-azure-active-directory-module-for-windows-powershell.aspx
Run the command prompt as an administrator by holding shift + right click on the command prompt icon, then Run as administrator.
At the command prompt
Change directories to where you AdministrationConfig-En.msi is installed.
In the command prompt type: msiexec /i AdministrationConfig-EN.msi
It will now install without the powershell warning.
Erik's commentary is that the powershell settings are only readable when privileges are elevated.
The beta version of the sign-in assistant which also needs to be installed prior to the Administrationconfig didn't help me but have helped others.
It was definitely a long and painful process.
There is a new beta version for the sign in assistant. Look up the new beta version and it will work. Just went through this about a week ago.
A String Value is "missing" in the registry. There are two potential locations in the Windows registry where PowerShell versions are stored, depending on what version or versions you have installed or possibly installed in the past.
Older version location, including Version 1.0 and 2.0:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1
Later versions location, including 5.0 and others:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3
Each location has a sub-key called PowerShellEngine that contains a string value called PowerShellVersion.
If this value is missing in the first key mentioned above, you will receive the installation error because the installer does not look the in the second key mentioned above for the PS version.
If the value is missing, simply add it with the data of 2.0
Now installation of the AADRM will work assuming you have PS 2.0 or later installed and assuming you are using the installer version 2.50 or later of the AADRM, which does not require the sign-in assistant to be installed.
I'm having a problem on my TeamCity CI build server where during compilation I get the following error:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9): error MSB3086: Task could not find "AL.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I've found similar reports from a year ago when people were upgrading to .NET 3.5, for example this one. In that case, installing the latest SDK solved the issue, however I have already installed the latest SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4) on my build server. The MSBuild tools are all there on the server, in a folder called
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
and AL.exe exists in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools
However the registry key mentioned in the error message does not exist. So, it seems like there is something wrong with the installation/configuration of MSBuild. This error only happens for projects that have embedded resources, which require AL.exe.
As you have install the latest SDK (I'm assuming that's v7.1)
Go to "Microsoft Windows SDK v7.1" from the Start menu
Select "Windows SDK 7.1 Command Prompt" and enter
cd Setup
WindowsSdkVer -version:v7.1
This will tell msbuild to use that version of the tools without needing to do any scary registry editing.
Even though the question is quite old but it still appears in the top of google search results so I decided to post my solution as well. I have trapped into same issue while during TeamCity setup on Windows Server 2016 and Windows 10 Pro.
I have installed Microsoft Build Tools 2015 and Windows 10 SDK (Only tools for .NET 4.6.2) and got the error from question.
The missing puzzle was to set environment variable: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.
After setting environment variable MSBuild was able to resolve all needed tools including AL.exe and build succeeded.
Please let me know if same can be achieved by setting values in registry, but otherwise environment variables also works very well in this case and no installation of VS is needed.
You also need to apply the following registry fix to update msbuild to point to the V7.1 sdk values.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1#InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86#InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools#InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0#MSBuildToolsPath)"
I had the same problem there, here's my simple answer to this.
After you have installed the Microsoft Windows SDK 7.1 on the TeamCity Server.
In Regedit Change this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86#InstallationFolder)
Follow the below steps. This worked perfectly to me. Saved my time.
1- Right-click the My Computer icon and choose Properties, or in Windows Control Panel, choose System.
2- Choose Advanced system settings.
3- On the Advanced tab, click Environment Variables.
4- Click New to create a new environment variable under User variable section.
5- Variable name: TargetFrameworkSDKToolsDirectory
6- Variable value: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
Variable value depends on your SDK installation path.
7- Click OK and Save all windows.
8- Restart Visual Studio.
I have a simple, effective fix.
The problem seems to be that the tools version delivered with Visual Studio is version 7.0A, while the version delivered with the Windows SDK is version 7.1. That's all very well, but MSBuild.exe is still looking for the version 7.0A registry keys, which don't exist. This has to be a bug!
Looking in my registry, all the information for V6.0 and V7.1 is present and correct. So my solution is simple. I created a registry link that makes an alias of the 7.1 keys.
It's not possible to create registry links using the built-in tools, so I downloaded a little utility called 'regln' from here.
C:>regln-x86.exe "\Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" "\Registry
\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1"
Job done. MSBuild now works perfectly on the TeamCity server.
Add a system env variable TargetFrameworkSDKToolsDirectory
like this:
TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
restart VS
Ran into the same issue setting up a new build server on Windows 10.
Found and installed the latest (at the time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 and that solved the problem.
We recently had this problem trying to get our .Net 4.0 builds working. We found that the location of al.exe had changed between where the original MSBuild that came with .Net 4.0 looks, and the Visual Studio SDK for .Net 4.0 (which was released later).
Since the only standalone installation of the SDK tools available is the one we had already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on the build agents. We put Visual Studio 2010 Express (to keep the installation as lightweight as possible) on there and the problem went away. Not a pretty solution, but it did work - installing VS2010 also installs the SDK tools of the specific version that MSBuild appears to be looking for.
This is a problem that really shouldn't happen, but there didn't seem to be a way of making MSBuild look in the correct place for the tools, even hacking around in the registry.