I downloaded the jdk and netbeans am trying to install it
but the error appears to me
cannot prepare bundled jvm to run the installer
How can I fix this issue?
Always check version of downloaded installer. If you have x64 system, and your installer is dedicated for x86 systems you will also see this error.
Cannot prepare bundled JVM to run the installer.
Look here: https://netbeans.org/bugzilla/show_bug.cgi?id=203431 (you should install ia32-libs, if you have Ubuntu/Debian)
Related
When I create solution in Jetbrains Rider EAP 21 I get "(with missing packages)" error in Solution Explorer window.
Then, I try to build project and get [MSB4057] error.
Despite this, I can run the project through Terminal:
dotnet restore
dotnet build
... and get following information:
Hosting environment: Production
Content root path: *path*
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
dotnet --info command result:
.NET Command Line Tools (1.0.3)
Product Information:
Version: 1.0.3
Commit SHA-1 hash: 37224c9917
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.3
I've resolved a similar problem by changing the MSBuild version in Settings > Build, Execution, Deployment > Toolset and Build > Use MSBuild version.
I've selected the MSBuild located in the Rider install directory.
I recently started receiving such errors in many of my projects. Initially I believed that it was because of Rider's version and rolled back, but instead, it was a problem with the latest MSBuild from the Visual Studio Installation (I use Windows).
The solution for me was to go to File | Settings | Build, Execution, Deployment | Toolset and Build and then tweak the Use MSBuild setting. By default, Rider used the MSBuild that was installed alongside Visual Studio. I changed it to use the MSBuild version installed with Rider instead and the problem went away. The same solution is also discussed in Jebtrains's bug tracking system
The problem was resolved by installing new version of Mono from official site
I'm using Visual Studio 2010 to build a MSI consisting of several DLL files set to register using vsdrpCOMSelfReg. There are also several Windows services that are installed using custom actions. My target machine is running Windows 32bit embedded standard.
My previous development box ran Windows 7 64 bit and I could build and install this MSI with no problem. I recently changed over to Windows 8 Pro, and when I build the MSI using the exact same code base I get "failed to register" errors on my DLLs, which then causes the services to fail installing.
I have a "Privileged" launch condition in the MSI that passes for both versions, so it looks like the required permissions are there.
If I set the DLL files to "vsdrpCOM" I can successfully register after the fact using regsvr32, but my services can't install because they rely on those DLLs being registered to complete their own installation.
What am I missing? What changed with DLL registry beween Windows 7 and Windows 8?
The usual cause for this is missing dependencies. ComSelfReg requires your Dlls to load and run during the install. If you have included the VC++ runtime support as merge modules and they install in WinSxS then they are not available until after your selfreg code needs to run. The symptoms are exactly those you'd get when the VC++ runtime is being installed from merge modules and do not already exist on the system - failure during the install and success with regsvr32 after the install.
In general you should look at using a tool that doesn't require code to install services. All the major install tools populate the ServiceInstall and ServiceControl tables in the MSI file because MSI will install services just fine, but VS setups don't use them for some reason.
The problem was in the dependencies automatically pulled in when I added the DLL Project Outputs. One of the detected dependencies was IPHLPAPI.DLL, pulled from C:\Windows\System32. This DLL was then copied into the application directory. In my install of Windows 8 Pro, IPHLPAPI.DLL is version 6.2.9200.16420. In Windows 7, this file is version 6.1.7600.16385.
I'm guessing my assemblies were referencing the Windows 8 version since that was in the local directory, and this caused registration and/or runtime errors. I excluded IPHLPAPI.DLL from the installer and everything is now running correctly, referencing the file in System32.
I have an *.msi installation that uses Wix Extensions :
WixFirewallExtension (To create firewall exceptions)
WixNetFxExtention (To create Native Images at install time)
This msi fails with the error "Installation ended prematurely..." when attempting to install on Windows Server 2003 (both 32 and 64 bit). It installs on Server 2008/Windows 7 etc with no issue.
Removing the firewall and native image parts before building the msi allow it to install normally but obviously without the extra options in place.
Does anyone know what the issue could be?
Here is the part of the log file that shows the failure but it doesn't say why it failed.
Other Notes:
Removing the firewall part but leaving the native image part still causes failure which is causing me to believe that any operation that uses an Extension will be affected.
The firewall configuration is set to ignore failures.
I have confirmed the firewall is enabled and running.
I have tried installing from an Administrator command prompt but this makes no difference
It sounds like a bug in the WiX v3.8 toolset. There were issues in earlier builds where the new VS2012 compilers did not support Windows XP. That was fixed in WiX v3.8.422.0 or newer. If you are not running the latest build of WiX v3.8, I recommend upgrading and seeing if the issue is fixed. If you are running the latest build of WiX v3.8 then you might open a bug: http://wixtoolset.org/bugs.
What is the issue?
I am trying to install FxCop 10. To install that, Microsoft Windows SDK 7.1 is required. I installed the SDK. Now, to install FxCop, I have to run FxCopSetup.exe, which is supposed to be located in the folder %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\FxCop. But, that folder is missing.
What I did to try to fix it?
I searched the web to fix the issue, and I tried a couple of workarounds that were suggested in a few discussions including (1) not doing a full installation of the SDK and (2) uninstall SDK, reboot, re-install SDK and reboot.
Any help is greatly appreciated. Thanks!
Btw, I'm running Windows 7 (if that's relevant).
In my SDK install, there is an FXCop folder: C:\Program Files\Microsoft SDKs\Windows\v7.0A\FXCop. Is there an FxCop folder somewhere in you SDK install? Apparently it's been moved...
Alternately, I have the FxCop installer on my Dropbox: http://dl.dropbox.com/u/1311259/FxCopSetup-10.0.exe
It's in Program Files, not Program Files(x86). I realized this when running a repair on the windows sdk when I couldn't find the folder, and seeing where it was copying files.
It worked for me when I only selected the "Tools" option to install.
I'd like to use Simd in Mono, but the following code is highlighted as error in MonDevop
using Mono.Simd
I already installed the "Mono 2.8 for Windows", what else I need to install to enable Mono.Simd?
In this link
http://tirania.org/blog/archive/2008/Nov-03.html
It talk about the tarbal, but after download it an uncompress it (mono-Mono.Simd.Math-942e804), there are many cs file and no dll file.
Did you add the Mono.Simd.dll to the build? MonoDevelop correctly highlights the error because in the assemblies you're using there isn't any Mono.Simd namespace.
Mono.Simd.dll is included in recent Mono releases.
As for the other answer, Mono.Simd works on any operating system on x86 and amd64, not only on Linux.
Mono.Simd only works when you run your programs on Mono runtime, on a supported operating system. If I'm not mistaken, it's currenly restricted to 32 & 64 bit Linux. Even if you manage to compile it on Windows, you won't get any speed benefit from it.
MonoDevelop for Windows runs on the .Net runtime, while the Mono.Simd.dll that comes with Mono 2.8 is installed in Mono's GAC.
You will need to Add Reference in your project to the Mono.Simd.dll that came with Mono 2.8.
It should be roughly in:
C:\Program Files (x86)\Mono-2.8\lib\mono\2.0\Mono.Simd.dll.