I recently acquired XMLSpy 2013 and was naturally excited to see there was a Visual Studio integration package. I'm running VS 2012, but nowhere on Altova's download page does it mention compatibility requirements/limitations.
So I followed the steps on the Altova download site (basically just run the package and you're done). Nothing changed in VS. So I decided to download the 1326 page PDF manual for XMLSpy to see if there was some extra help in there:
http://www.altova.com/documents/XMLSpyPro.pdf
On page 490, it mentions going into your VS/Common7/IDE directory and running devenv.exe /setup which I did. After that, again, nothing changed.
Has anyone had any success with getting this integration package to work? I can find almost no information by searching the web.
I actually created a support ticket with Altova for the issue as well, but thought I'd try here for some first hand experiences.
Whelp, Altova support responded to my ticket. The answer is, since Visual Studio is a 32-bit only application, XMLSpy integration will not work when running the 64-bit version of XMLSpy/XMLSpy integration package.
This is despite the fact that both a 64-bit version of XMLSpy AND a 64-bit version of the Visual Studio Integration package exist side-by-side on the download page (as of writing this answer). I have a feeling that it might only exist for the Eclipse integration.
http://www.altova.com/download/xmlspy.html
Once I installed the 32-bit versions of XMLSpy/Integration package, it all worked as promised. I hope this helps someone in the future at least.
Related
I used Flexera's InstallShield Express to bundle my software into a Setup.exe file. I included .NET Framework 4.7.1 redistributable (2. Specify Application Data > 'Microsoft .NET Framework 4.7.1 Full' is checked and highlighted in middle panel, and says 'installed locally' > 'Install before feature selection' is checked on bottom panel).
I went onto my fresh installed Windows 7 computer with no internet access and attempted the install. It gave me the error:
"An error occurred while downloading the file
http://saturn.installshield.com/is/prerequisites/Microsoft.NET Framework 4.7.1 Full.prq"
I then connected to the internet, and it was able to go through. I looked for a text of the prq. There may be a way to find it thru InstallShield, but I found a forum post from community.flexerasoftware.com asking about 4.7.2.
The two parts of interest are:
<file LocalFile="<ISProductFolder>
\SetupPrerequisites\Microsoft .net\4.7.1\Full\NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
URL="https://download.microsoft.com/download
/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
FileSize="0,0"/>
and
<properties Id="{BFF4A593-74C5-482F-9771-7495035EBBB0}"
Description="This prerequisite installs the .NET Framework 4.7.2 Full standalone package."
AltPrqURL="http://saturn.installshield.com/is/prerequisites
/Microsoft .NET Framework 4.7.2 Full.prq"/>
The fact that the file reads '4.7.1' is another can of worms I need to explore (not in the scope of this question). I'm assuming all prq files have a common structure. I believe that this information tells me the URL (download.microsoft.com) was skipped and the AltPrqUril (saturn.installshield.com) was used during my install. But even if the URL were not skipped, it would still looking at a page on the world wide web.
Question
Why do I need internet connection? The 'Full' version is specifically different from the 'Web' version in that you do not have to connect to the internet to install it.
Avoiding Internet Connection Requirement
To embed runtimes in the setup.exe and hence avoid the need for
an Internet connection, you can try to set the option "Extract
prerequisites from setup.exe" in the setup.exe tab in the
Release view as illustrated in the second screenshot below.
Then you select the "Full" .NET Framework version in the
Prerequisites View. Not 100% sure what features the Installshield Express version has vs the full versions. The below is from the Premier version.
You can check your finished bundle, by doing a "setup.exe /a" -
from a command prompt - on the final
setup.exe and extract the files to see what is really included in the bundle.
Quick Reminder
I think you should generally call Installshield support if you have a support agreement, or check their own community at: https://community.flexerasoftware.com.
Just mentioning this since people sometimes forget to check whether they have support agreements and support & community might resolve your problems in 5 minutes - if you don't get answers here.
Release Wizard
However, just shooting from the hip I would propose that the cause could be this setting that is available in the Release Wizard in the regular version of Installshield 2018. It is probably similar in the Express edition:
In the Release property pages, it seems this setting is under the Setup.exe tab and it is called "Installshield Prerequisites Location":
[
Prefer Download
For what it is worth I really dislike old, outdated runtimes included in bloated setups. This has to do with my experience as a corporate deployment specialists where much of the day consisted of extracting outdated runtimes from vendor packages.
I would always suggest you download very common runtimes from the web, or allow them to be installed via Windows Update. That includes basically all Microsoft runtimes.
I only like to bundle runtimes if they are 1) Rare and special, 2) Stable and well tested, 3) Small and well-behaving. Even then I would prefer them downloaded and installed separately - to allow security fixes to be installed without rebuilding your whole setup - you just put up the new runtime version on your server (marketing will want a new build for physical release - that is just added risk if you ask me).
War story: the SOAP merge module - back in the day - almost destroyed my package with global deployment scope. Deployment errors quadrupled. Prerequisites can really ruin your work, and you will face little understanding for the problem seen. Try to make it clear what breaks and why. And get rid of all prerequisites you can (pie-in-the-sky thinking, I know). Certain runtimes are unavoidable of course. I just ramble on :-).
I am trying to build a few different 32-bit C++ applications with Visual Studio 2015 that use CEF. To use CEF, I am currently acquiring the CEF prebuilts from Spotify. The dll wrapper for CEF is built using Visual Studio 2015 with some modifications to its CMake files to force it to build with MD and MDd mode regardless of other settings. This was sufficient to make these C++ applications run on some machines. Any machine on which Visual Studio 2015 is installed on before anything else they can run on, however some machines seem to exist in a state such that the program will produce an error on starting when lacking the MSVC 2015 runtime (as expected), but when adding the MSVC 2015 runtime the program simply crashes; however, it only crashes after CEF is used. These programs work fine when they don't link to libcef.dll and don't include the browser functionality.
Upon investigating, I found that libcef.dll, as built by spotify, links to MSVCP110_WIN.DLL, which is from the Visual C++ 2012 Redistributable package. Naturally, the application I am building links to MSVCP140.DLL, which is from the Visual C++ 2015 Redistributable package. This means that the application ultimately links to two runtimes simultaneously. I do not know if this is an issue, but so far it seems to be my best lead. Installing the Visual C++ 2012 Redistributable does not change the outcome and it continues to crash when CEF is used.
This issue has been witnessed on both Windows 7 and Windows 10 and the application works without CEF on both of those operating systems as well, so the operating system is not likely to be the cause of the failure on these systems specifically.
Has anyone else encountered this issue and does anyone know a workaround? Also, does anybody know if it is okay to mix these two runtimes and what the limitations are? It seems that the installation history of a given machine affects the success of running the application, so any hints into what combination of things leads to this failure would be helpful as well.
You have some options:
Use the lastest version of VS that will allow a selection of Platform Toolset that matches libdef.dll. For example, VS2013 might allow the selection of the 2012 CRT.
Or convince Spotify to rebuild libcef.dll such that it matches your version of CRT
Or convince Spotify to not release libraries that depend on the CRT (yes that's probably a bit of work).
Or make a small app built against the older CRT, this app can then successfully use libcef.dll. Then you get to use any IPC technique so that your main VS2015 app can talk to this wrapper. Running out-of-process is one way to segregate the unruly third party libraries.
EDIT:
This is open source? Well good news, you can fix this yourself, built the CEF against your favorite version of VS.
I've updated Visual Studio 2015 to Update 2 recently. Since then, I'm not able to compile my already published app anymore. Even a new blank UWP project does not compile. I get the following error message:
ILT0005: "C:\Program Files (x86)\MSBuild\Microsoft.NetNative\x86\ilc\Tools\nutc_driver.exe #"C:\Users\locked\documents\visual studio 2015\Projects\App1\App1\obj\x86\Release\ilc\intermediate\MDIL\App1.rsp"" Exitcode -1073740791
I completely uninstalled all Visual Studio relevant components and reinstalled them, which didn't solve the problem. Unfortunately, I'm not able to update my app at the moment.
I'm running Windows 10 Build 10586.218
It is a bug in .NET Native compiler, affecting German localization only (based on our current knowledge). We are looking into solutions (a fix with reasonable shipping vehicle, or better workaround). Stay tuned.
[Update] The fix shipped on 6th May as "Universal Windows App Development Tools - Tools (1.3.2)". Go to Control Panel - Programs - Programs and Features - Visual Studio ... - Modify, check Tools (1.3.2), then click Update. All languages now work (German, French, Italian, etc.).
-Karel Zikmund
(.NET Native team)
i had exactly this issue on french platform and found this solution : https://social.msdn.microsoft.com/Forums/en-US/9d590372-d82c-4075-9ea9-504a22c9502f/cant-compile-in-net-native-ilt005-error?forum=wpdevelop
compilation is ok after moved all ressources files nutcui.dll
I tried tutorial steps for Visual 2010, the linking didn't work or the console doesn't respond to build or run. I tried for other options to configure, which also didn't work as well.
You may vote for a request for enhancement at https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=85231
regards
Alex Fleischer
It can be a bit complicated...
First, I think you should start reading the following tutorial. I find it quite straightforward as adapted to any CPLEX version. You must only notice that using a CPLEX version 12.X translates into the usage of its library: cplex12X.lib, the tutorial referring to CPLEX v12.61.
Then, you must install Visual Studio 2012, or even 2010, as they will install another Platform Toolset, v110 for VS2012 or v100 for VS2010. This is required since CPLEX comes with libraries for the 2010, 2012 and 2013 only, there is none so far for VS2015.
The configuration might work even if you have already VS2015 installed on your computer but I strongly advise you to begin installing the older version first, then the VS2015 to ensure the latter will recognize the older Platform Toolset and give you the option under: View\Property Pages\Configuration Properties\General\Platform Toolset of choosing the v110 for your project.
Be aware that using only VS2015 will prompt you a bunch of LNK2038 mismatch detected for '_msc_ver' errors letting you know that you're using version 1800 whereas you're linking libraries compiled on 1600 or 1700 versions.
One is glad to be of service
As of CPLEX 12.6.3, VS2015 is not supported (see the detailed system requirements here). It is possible to use VS2015 with a VS2013 project (e.g., see here), but this is probably not what you are looking for.
I develop an unmanaged DLL with Visual C++ which is part of my application. I have always had various problems with linking the VC runtime library. Somehow I managed with VS 2005, but since I moved to VS 2008, the release version of my DLL no longer works on any PC other than the one with my development tools (namely VS 2008).
I link the runtime library as multi-threaded DLL (/MD). I tried the /MT option but that causes a lot of error messages. I allow isolation of the manifest file, and of course installed the VC++ 2008 runtime (although I don't think it should be needed). I also tried the dependency walker to check what is missing. On my development PC (VS 2008 SP1 installed) three files are reported missing:
MSVCR90.DLL, GPSVC.DLL, IESHIMS.DLL
But that does not stop the application (and my DLL) from running.
On all other PCs I tried to install my application on, apart from these three, a fourth file is reported as missing by dep. walker: MSVCP90.DLL.
More importantly, my own DLL is not working as well.
I know this is nothing new and I tried to read everything I could find about SxS problems but I still don't know what to do. Hopefully my description of the 'phenomenon' is good enough for someone more experienced to give me some help.
Thanks in advance.
You may need to distribute and install Microsoft Visual C++ 2008 Redistributable, OR SP1 versionf of it.