I post the following question at LunarG, as Issue #565, about Vulkan SDK redistributable parts for ready to go applications developed with Vulkan. I'd like to share it with Stack Overflow developers.
Let's say I have Vulkan application demo and wish to send it to
potential clients, in order to evaluate it. If I'd develop it using
SDK, what is the correct way to deploy it :
a) include the compatible SDK installer in a multi-install process ?
b) include some SDK's dlls and companion files ? Which ones ?
It also raises another question: Can I re-distribute SDK files ?
Karl Schultz, from LunarG, replied with the following:
On Windows, many IHVs include the Vulkan loader DLL in their install
packages, placing it in system32/vulkan-1.dll. So, in many cases, your
app might just work fine as long as the user has installed drivers
with Vulkan support.
You might also consider shipping only the RunTimeInstaller, which is
found in the SDK. This would let the user install the run time
(loader) as part of your application install. The RTI includes version
checking so that it doesn't clobber a newer version installed by IHV
drivers, or vice-versa. In short, this is probably the best way to go.
It would be better to include the RTI as part of the "multi-install
process" rather than include the entire SDK.
If your application needs layers or some other specific item from the
SDK, then you'd have to include those explicitly somehow.
Please check the licensing-related files within the SDK concerning
redistribution.
Related
Ther are many articles about how to install spread library on Linux(1. download source & unzip it 2.run ./config 3. make 4. make install) but seems no article about how to install spread on Windows......
I had downloaded spread-bin-4.4.0-Windows8_x64 from official site(my environemnt is win10), but there is no .bat or .exe file found under the unzipped folder. Does anyone know how to install spread library on Windows?
In linux, there is a standard way of installing libraries that all the software on your machine is supposed to use. In part this works because all that software is chosen in such a way that the same versions of libraries will satisfy everyone, that's what makes up a linux distribution to some extent.
In windows, the model of development is totally different. Any third party software, not from microsoft, is something the customer paid for and microsoft never signs off on it or anything. Third party stuff generally is supposed to provide its own libraries since you have no idea what other third party stuff is present. There's not much point in globally installing things since most programs won't use what you globally install anyways.
So, if you have a library on windows, you should install in whatever way the program that you intend to use it with will find it. If you are intending to install it for use with a project you are developing, that is a different question, and ultimately one about your build system or IDE.
In modern days there are things like NuGet which allow you to do things in a more linuxy way on windows. But that's quite recent and not that much software from typical user's perspective gets its dependencies that way.
After further study, I found a Visual Studio solution file:spread.sln under \win32 folder! So in conclusion, to install Spread libarary on Windows:
1. get source codes from http://www.spread.org/download.html
2. unzip
3. open solution file under \win32 folder with Visual Studio
(Please note that "do not" use relatively new version of VS since this solution is built with older VS(like VS 2010) otherwise unexpected errors occurred)
4. build solution
There you go! You can build your project with Spread library now!
P.S. This spread.sln is a Win32 solution. I'm just wonder is there a Win64 version solution file......
I've recently made a Windows Forms Application in VS 2010 Express. When running on my machine it works fine but on other machines it needs to install the .NET framework first. Is there anyway around this? By including the library in my executable? By not using the .NET framework?
I would really appreciate some help.
Typically this kind of problem would be handled by your Windows Forms Application's installation package.
Opinions vary but I'd suggest the safest/most polite thing to do is to treat .NET as a prerequisite. If .NET is not present, display a message that it is required before the install will succeed and perhaps point to a Microsoft download page like this one or this one. The risk is that you point them to an obsolete download page or that the page moves and invalidates your link.
That said, I would have expected most machines to have some version of the .NET Framework installed (by Windows Update for example) so it's a bit surprising that you're being told it needs to be installed.
I suggest you follow the instructions in How to: Determine Which .NET Framework Versions Are Installed to check one of your failing machines to confirm that .NET is not installed (very unlikely) or to determine which version (or versions) of .NET is (are) installed.
Update 6/21/2015 From the comment below, we have evidence of two systems without .NET installed so my "very unlikely" comment above is a bit off base!
Update 7/4/2015 I have a bad habit of forgetting that not everyone configures their Windows systems exactly the same way I configure mine. From this blog post it seems that the .NET Framework is 'only' a Recommended Update.
I've been looking online and at my registry and I think not, but it would be nice if we could get a definitive answer on here.
Just the run time, as in for re-use on the client side.
I see it is possible for VC10, http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx, but prior to that we need to call the MsiQueryProductState API. Perhaps just give all the clients MSVCR100.DLL already?
The most common practice is to install the CRT your application was built with, regardless.
I think this practice comes from the v90 and lower CRTs, because there were multiple versions of each redistributable that could be installed, and though MSVCR90.DLL exists on the system, it may not be the version your application uses.
I believe this was changed with the v100 CRT, and now Microsoft guarantees that newer versions of the CRT will be usable in place of an older version, but I would still attempt to install the CRT your application was linked with.
It is still possible to do a private install of the Dll's into the application's folder. I recently installed 3 different version of the VC9 runtime when I was setting up my Visual Studio Express environments. All show up in Control Panel and appear to be readily removable.
For that reason I believe the current best practise to be to perform a private install (I think that is the terminolgy MS uses) of the required DLL's (for managed code you need the managed DLL and the native version) in tha app's folder.
My company is thinking of dumping InstallShield and move to something else, mainly because of the poor experience it had with it, mostly on Linux.
Our product is a C++ application (binaries, shared libraries) targeted at Windows and Linux (Red Hat).
The installer itself isn't required to do anything special, just dump some binaries and shared libraries and sometime execute an external process. Things like version upgrading through the installer isn't necessary, this is handled after the installer finishes.
I thought of suggesting using NSIS on Windows and RPM on Linux.
What are the recommended installer systems to use when deploying to Windows/Linux? Something that is cross platform to prevent maintaining two installers is a definite plus.
For Windows I would definitively use NSIS. It's very lightweight, easy to code and very simple to understand. Using msis would just be a killer - it generates guid for every file so you can get upgrades for free and stuff but truth being said, you never end up using any of these.
Regarding Linux I would go for RPM and Deb. They're probably the two biggest packaging system so you'll be targeting most of the Linux users. I've never tried RPM but creating a Deb package is fairly straightforward.
See also:
What to use for creating a quick and light setup file?
Packaging to use to deploy cross-platform?
And even:
Creating installers for complex cross-platform programs
There's a tool called BitRock Installer which can create installers for Windows, Linux and OS X.
However, I think that if you target RedHat it would be better to provide native packages for that platform (that is .rpm).
For C++ projects, I'd go with cmake/cpack, if you are also willing to change your build system. Great support, strongly cross-platform. cpack has various generators, NSIS is one..
Take a look at InstallJammer. It will handle both platforms from the same build project, and you can have the installer register the package with the RPM database as well if that's your requirement.
You may want to consider our tool BitRock InstallBuilder , it can generate installers for Windows and Linux from a single project file and also RPMs. Is your application based on Qt? Our clients include the makers of Qt, Nokia (previously Trolltech) and they use it to package their Qt Creator product. We encourage to give InstallBuilder a try and contact our support with any questions or suggestions you may have.
Sorry i'm a beginner,from what i know there are number of varieties of libraries and framework out there provided for the C++ language.My question is,when we create an application using the framework and libraries,do the users of the application need to install the framework or so so call the libraries on his/her PC??Thank You
It depends whether the library you are using is statically or dynamically linked. In the former case, it is part of the executable file that you distribute. In the latter case, it is an extra file (or set of files) with extensions such as .so or .dll, which you should distribute with your app.
Yes, libraries must be bundled with your application/installed before hand, as they are the framework upon which your application relies. If you don't install the framework, your application will not work.
You need to install something, not necessarily the framework. Some frameworks, like DirectX for example have a client installation. Some components are simple dll files that you can deliver with your software, creating an installation package.
The end-user need to have the framework installed.
As you need to have .Net installed to run some Microsoft(and other companies) products. If your application is written in C++ using GTK or Qt. You need to have they installed, but if you're on Linux using KDE, Qt is natively installed for default, the same for Gnome and also the same of Cocoa on Mac and Cocoa-Touch on iPhone and iPod Touch.
I suggest you to have the installer of the framework used embedded on the installer of your application. As GIMP and Xchat do.
Generally when using a framework there will be a framework redistributable (.NET, DirectX, etc) which can be bootstrapped into your installation to install the framework (or run by the end user as the first part of "installing" your app).
Many libraries simply need to be included with your code to function correctly, they themselves might have dependencies which need to be installed but these should be called out.
If in doubt, before you distribute your package run it on a fresh install of your target system (Linux, Windows, etc) and see if it complains about missing dependencies. Include those in your package and try again.
You can also look at installation systems (RPM, Apt, Windows Installer, etc) which can handle all of these tasks for you directly (or provide scripting languages to help you automate the job).