How To Install Windows Sdk 7.0a WORK
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 [C:\TCAgents\wmdev\wmdev2\work\90d22fe21252707d\source\src\......]
How To Install Windows Sdk 7.0a
Windows SDK allows the user to specify the components to be installed and where to install them. It integrates with Visual Studio, so that multiple copies of the components that both have are not installed; however, there are compatibility caveats if either of the two is not from the same era.[4][5] Information shown can be filtered by content, such as showing only new Windows Vista content, only .NET Framework content, or showing content for a specific language or technology.
The tool is installed in the \Bin folder of the Microsoft Windows Software Development Kit (SDK) installation path, for example: C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\signtool.exe.
Windows PowerShell 3.0 is automatically installed with Windows 8 and Windows Server 2012. Inaddition, you can download and install the reference assemblies for Windows PowerShell 3.0 as partof the Windows 8 SDK. These assemblies allow you to write cmdlets, providers, and host programs forWindows PowerShell 3.0. When you install the Windows SDK for Windows 8, the Windows PowerShellassemblies are automatically installed in the reference assembly folder, in \Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0. For more information, see the Windows 8SDK download site. Windows PowerShell code samples are also available in thepowershell-sdk-samplesrepository.
Windows 7 and Windows Server 2008 R2 automatically have PowerShell 2.0 installed. In addition, youcan install PowerShell 3.0 on these systems. You can also install the Windows 8 SDK on Windows 7 andWindows Server 2008 R2 as described above.
Code that is compiled against the Windows PowerShell 2.0 assemblies cannot be loaded into WindowsPowerShell 1.0 installations. However, code that is compiled against the Windows PowerShell 1.0assemblies can be loaded into Windows PowerShell 2.0 installations.
Code samples are installed in the following location by default: C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\sysmgmt\WindowsPowerShell\. The following sections provide a briefdescription of what each sample does.
The Windows SDK V7.1 was already installed on the server. And also the .Net Framework SDK 2.0 was installed (and probably used in the afterbuild)I tried setting the active SDK version by using the SDK tool: WindowsSdkVer.exe -version:v7.1 . That does not help.Using the WindowsSDKDir instead of FrameworkSDKDir does not helpAdding the two dir items in the system configuration does not help.Adding an extra backslash does not help.When I hardcode the correct folder, I have no problem.
One small problem left for me: Not for all the developers this works. We will fix that by ourself. But maybe you have a simple solution:When I use FrameworkSDKDir all developers (with VS 2010 installed) are happy. But I do not want to install VS on the build machine. So There I have the Win SDK installed. And so the build is happy with WindowsSDKDir.Is there a way in the DotNetConfig to be able to use the FrameworkSDKDir on the build server? If not, we will fix this on the developers machines.
I understand why microsoft struggles with this, because this is something that depends of the SDK you have installed on your (build) machine, but also belongs to the project settings, where you declare what .Net framework you target. Maybe we would be best off when both settings would be a solution wide setting.
Beginning with JD Edwards EnterpriseOne Tools Release 9.1 Update 3.3, the IBM WebSphere Application Server Release 8.5.5 is supported. This fix pack can be installed as a new installation or an update.
Relative to WebSphere 7.0, with IBM WebSphere 8.5 the installation procedure has changed dramatically. You will now use the IBM Installation Manager as a central hub to manage the installation process. The IBM Installation Manager is designed to make the installation procedure much simpler and easier than in prior releases.
Additionally IBM WebSphere Application Server 8.5 supports SDK 1.6 as the basic configuration but with SDK 1.7 as an optional configuration. For JD Edwards EnterpriseOne, the implementation requires SDK 1.7 as the default run-time configuration for WebSphere Application Server 8.5. Therefore, after WebSphere Application Server is installed with the basic configuration, you MUST change the default SDK to 1.7.
In WebSphere Application Server Version 8.5 information Center, review the section entitled: "Preparing the operating system for product installation". Update your system according to the requirements.
By default, the IBM WebSphere Application Server runs as root. However, it can also be run by using a non-root user ID. The non-root user can install WebSphere Application Server in both silent and interactive nonAdmin mode for full product installations and removals, incremental feature installations, and edition upgrades.
If some portion of an installation requires administrator privileges, Installation Manager provides an option so that the non-administrator can install an operational product without enabling the privileged option whenever possible.
IBM WebSphere Application Server (WAS) 8.5 is installed through the IBM Installation Manager. Fix Pack 8.5.5 can be installed as a new installation or an update. For purposes of this procedure, all references are to release 8.5, but you can substitute 8.5.5 where applicable.
You must configure the software repository in the Installation Manager before you can start the product installation. On the initial screen of the IBM Installation Manager, navigate File > Preferences.
On Install Packages, select location for the shared resources directory, enter an appropriate location for IMShared. These files will be used by all IBM products installed through the Installation Manager (such as HTTP Server and Customization Toolbox).
You can choose to create your first profile now or after the remaining software packages have been installed. If you create your profile now, you will need to manually define the web server before configuring the plug-in later in this chapter. As an alternative, you can use the advanced profile creation option to automatically create a web server, but this must be done after all of the other software components described in this guide are installed and updated to the correct level.
On Install Packages, package group, click the radio button entitled: Create a new package group. In the Installation Directory field, enter an appropriate location to install the IBM HTTP Server 8.5 software. It does not have to be the same location as the shared location.
This document refers to a local IBM HTTP server installed on the same machine as the IBM WebSphere Application Server. For instructions on how to install a remote HTTP server, refer to the IBM info center:
New tool functionality with IBM WebSphere 8.5 includes the requirement to install the WebSphere Customization Toolbox. This tool aids in configuring your plug-in properly. The WebSphere Customization Toolbox comes from the supplemental software repository that was downloaded, decompressed, and added to the repository list as described in previous procedures in this document.
After you have updated all software packages as described in the preceding section of this document entitled: Section 3.10, "Installing or Updating to WebSphere 8.5 Fix Pack", you must configure the plug-in. This process is performed through the IBM WebSphere Customization Toolbox. You must complete this configuration before you install the JD Edwards EnterpriseOne HTML Web Server.
The WixNetfxExtension also includes a set of properties that can be used to detect the presence of various versions of the .NET Framework, the .NET Framework SDK and the Windows SDK. For information on how to use these properties to verify the user's .NET Framework version at install time see How To: Check for .NET Framework Versions.
The following properties (available starting in WiX v3.10) let you detect a particular minimum version of .NET Framework 4.X releases that are in-place updates (rather than that are installed side-by-side with other releases):
according to -us/library/windows/desktop/dd323661(v=vs.85).aspx,the SoucePath in the CREATE_VIRTUAL_DISK_PARAMETERS structure is"Optional fully qualified path to pre-populate the new virtual disk object with block data from an existing disk.This path may refer to a virtual disk or a physical disk."
Found similar posts with identical question without answers. -US/windowsgeneraldevelopmentissues/thread/5e37d0c7-8c76-4547-a3f0-41ffa8dc2ea4/ -6e21-491b-9d4f-e3bc2426555f -vhd-files-with-the-virtualdisk-api -access-denied-when-using-the-function-createvirtualdisk-in-win7 -access-denied-function-25070.aspx
p.s.env: VS2010 + sp1, Windows SDK 7.1 and 7.0a, on Windows 7 professional x64 + sp1,running with elevated privilegessource code: assign the fully qualified path to "params.Version1.SourcePath" in the following code.
I've probably been reading the same blog posts as you have, because I didn't dare install any of those "service wrappers". I don't want to but if I can't find anything useful, I'll code a wrapper myself. We're running multiple build agents that potentially could build and test projects at the same time, so starting Selenium from the build script would not work unless you configure each project to run Selenium on dedicated TCP ports.. But that seems like a huge hassle.
This README file contains build instructions for the OpenJDK. Building the source code for the OpenJDK requires a certain degree of technical expertise. Contents Introduction
Use of Mercurial Getting the Source
Minimum Build Environments
Specific Developer Build Environments Fedora Linux
CentOS Linux
Debian GNU/Linux
Ubuntu Linux
OpenSUSE
Mandriva
OpenSolaris
Source Directory Structure Managing the Source Drops
Build Information GNU Make (gmake)
Basic Linux System Setup
Basic Solaris System Setup
Basic Windows System Setup
Build Dependencies Bootstrap JDK
Optional Import JDK
Ant 1.7.1
Certificate Authority File (cacert)
Compilers Microsoft Visual Studio Professional/Express for 32 bit
Microsoft Visual Studio Professional for 64 bit
Microsoft Windows SDK for 64 bit
Linux gcc/binutils
Sun Studio
Zip and Unzip
FreeType2 Fonts
Linux and Solaris: CUPS Include files
XRender Include files
Linux only: ALSA files
Windows only: Unix Command Tools (CYGWIN)
DirectX 9.0 SDK
Creating the Build
Testing the Build
Environment/Make Variables
Troubleshooting
Use of Mercurial The OpenJDK sources are maintained with the revision control system Mercurial. If you are new to Mercurial, please see the Beginner Guides or refer to the Mercurial Book. The first few chapters of the book provide an excellent overview of Mercurial, what it is and how it works. For using Mercurial with the OpenJDK refer to the Developer Guide: Installing and Configuring Mercurial section for more information. The Forest Extension is not part of the Mercurial install, and is optional, but can be obtained with the following commands: hg clone -crew/overview/ YourHgForest Once you have the file forest.py, you need to add these lines to your $HOME/.hgrc file: [extensions] forest = YourHgForest/forest.py Getting the Source To get the entire set of OpenJDK Mercurial repositories using the Forest Extension: hg fclone YourOpenJDK To get the entire set of OpenJDK Mercurial repositories without using the Forest Extension: hg clone YourOpenJDK cd YourOpenJDK sh ./get_source.sh Once you have all the repositories, the script make/scripts/hgforest.sh can be used to repeat the same hg command on every repository in the forest, e.g. cd YourOpenJDK sh ./make/scripts/hgforest.sh pull -u You may find this script make/scripts/hgforest.sh faster than the hg forest commands provided by the Forest Extension. Minimum Build Environments This file often describes specific requirements for what we call the "minimum build environments" (MBE) for this specific release of the JDK, Building with the MBE will generate the most compatible bits that install on, and run correctly on, the most variations of the same base OS and hardware architecture. These usually represent what is often called the least common denominator platforms. It is understood that most developers will NOT be using these specific platforms, and in fact creating these specific platforms may be difficult due to the age of some of this software. The minimum OS and C/C++ compiler versions needed for building the OpenJDK: Base OS and Architecture OS C/C++ Compiler BOOT JDK Linux X86 (32-bit) Fedora 9 gcc 4.3 JDK 6u18 Linux X64 (64-bit) Fedora 9 gcc 4.3 JDK 6u18 Solaris SPARC (32-bit) Solaris 10 Update 6 Sun Studio 12 Update 1 + patches JDK 6u18 Solaris SPARCV9 (64-bit) Solaris 10 Update 6 Sun Studio 12 Update 1 + patches JDK 6u18 Solaris X86 (32-bit) Solaris 10 Update 6 Sun Studio 12 Update 1 + patches JDK 6u18 Solaris X64 (64-bit) Solaris 10 Update 6 Sun Studio 12 Update 1 + patches JDK 6u18 Windows X86 (32-bit) Windows XP Microsoft Visual Studio C++ 2010 Professional Edition JDK 6u18 Windows X64 (64-bit) Windows Server 2003 - Enterprise x64 Edition Microsoft Visual Studio C++ 2010 Professional Edition JDK 6u18 These same sources do indeed build on many more systems than the above older generation systems, again the above is just a minimum. Compilation problems with newer or different C/C++ compilers is a common problem. Similarly, compilation problems related to changes to the /usr/include or system header files is also a common problem with newer or unreleased OS versions. Please report these types of problems as bugs so that they can be dealt with accordingly. Specific Developer Build Environments We won't be listing all the possible environments, but we will try to provide what information we have available to us. Fedora Fedora 9 After installing Fedora 9 you need to install several build dependencies. The simplest way to do it is to execute the following commands as user root: yum-builddep java-1.6.0-openjdk yum install gcc gcc-c++ In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk Fedora 10 After installing Fedora 10 you need to install several build dependencies. The simplest way to do it is to execute the following commands as user root: yum-builddep java-1.6.0-openjdk yum install gcc gcc-c++ In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk Fedora 11 After installing Fedora 11 you need to install several build dependencies. The simplest way to do it is to execute the following commands as user root: yum-builddep java-1.6.0-openjdk yum install gcc gcc-c++ In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk CentOS 5.5 After installing CentOS 5.5 you need to make sure you have the following Development bundles installed: Development Libraries
Development Tools
Java Development
X Software Development (Including XFree86-devel)
Plus the following packages: cups devel: Cups Development Package
alsa devel: Alsa Development Package
ant: Ant Package
Xi devel: libXi.so Development Package
The freetype 2.3 packages don't seem to be available, but the freetype 2.3 sources can be downloaded, built, and installed easily enough from the freetype site. Build and install with something like: ./configure && make && sudo -u root make install Mercurial packages could not be found easily, but a Google search should find ones, and they usually include Python if it's needed. Debian Debian 5.0 (Lenny) After installing Debian 5 you need to install several build dependencies. The simplest way to install the build dependencies is to execute the following commands as user root: aptitude build-dep openjdk-6 aptitude install openjdk-6-jdk libmotif-dev In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk Ubuntu Ubuntu 8.04 After installing Ubuntu 8.04 you need to install several build dependencies. First, you need to enable the universe repository in the Software Sources application and reload the repository information. The Software Sources application is available under the System/Administration menu. The simplest way to install the build dependencies is to execute the following commands: sudo aptitude build-dep openjdk-6 sudo aptitude install openjdk-6-jdk In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk Ubuntu 8.10 After installing Ubuntu 8.10 you need to install several build dependencies. The simplestway to do it is to execute the following commands: sudo aptitude build-dep openjdk-6 sudo aptitude install openjdk-6-jdk In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk Ubuntu 9.04 After installing Ubuntu 9.04 you need to install several build dependencies. The simplestway to do it is to execute the following commands: sudo aptitude build-dep openjdk-6 sudo aptitude install openjdk-6-jdk In addition, it's necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk OpenSUSE OpenSUSE 11.1 After installing OpenSUSE 11.1 you need to install several build dependencies. The simplest way to install the build dependencies is to execute the following commands: sudo zypper source-install -d java-1_6_0-openjdk sudo zypper install make In addition, it is necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk Finally, you need to unset the JAVA_HOME environment variable: export -n JAVA_HOME Mandriva Mandriva Linux One 2009 Spring After installing Mandriva Linux One 2009 Spring you need to install several build dependencies. The simplest way to install the build dependencies is to execute the following commands as user root: urpmi java-1.6.0-openjdk-devel ant make gcc gcc-c++ freetype-devel zip unzip libcups2-devel libxrender1-devel libalsa2-devel libstc++-static-devel libxtst6-devel libxi-devel In addition, it is necessary to set a few environment variables for the build: export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk OpenSolaris OpenSolaris 2009.06 After installing OpenSolaris 2009.06 you need to install several build dependencies. The simplest way to in