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.
Related
I am planning to migrate site core 6.5 to site core 8.1. So here i am using below dlls sample
Sitecore.nexus
Sitecore.NVelocity
Sitecore.Analytics
Sitecore.Marketing.Wildcards and etc.
While i am doing POC i got understand Sitecore.Marketing.Wildcards is changed because of vast changes in Rules Engine.I figured out by compile time errors in my code after code has setup with sitecore 8.1. So i planned for another work around.
My question is how can I find a way to discover deprecated or changed functions from one version to another version of site core migrations? I'm trying to fgire this out before I dive into development.
The best way is to go through the release notes and find what is changed.
https://dev.sitecore.net/Downloads/Sitecore%20Experience%20Platform/Sitecore%2081/Sitecore%20Experience%20Platform%2081%20Initial%20Release/Release%20Notes
For example, on the release notes for Sitecore 8.1 on above link, you will find certain deprecated features, functionality, framework like SPEAK 1.1 framework etc. So with every release, some features or components may get deprecated and you need to fix the code break due to this.
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.
I have made an application which utilises Microsofts Directx9 as a graphics API, and it runs fine on my computer but on other computers, it asks for dlls mainly msvcrt and d3d runtime related. So how do I make sure that my application will run everytime someone executes it who doesn't know what vcrt or directx is? Do I supply the runtime packages with my app? Though it is not feasible for a 2MB application. what to do?
As Nicol Bolas points out below, DirectX (and Visual C++) must be installed on the users machine for them to use your application.
I previously recommended bundling the DirectX Web Installer because it pretty small, but as Ross Ridge mentioned, this might not be a legal way of distributing DirectX. Microsoft recommends to not bundle the Web Installer, but use the redistributable package instead:
Always Install DirectX, and Do So Silently
It is strongly recommended that the game silently install the DirectX
redistributable that the game was built against. The DirectX
installation process is designed so that it verifies whether anything
needs to be updated and quickly returns if it doesn't. So, there is no
need to ask users if they want DirectX installed. A silent
installation of DirectX can be done by running this command from your
installation package: dxsetup.exe /silent
Asking a user if he wants to install DirectX can cause many problems.
For example, if the user assumes he has the latest redistributable
installed and chooses to skip installation of DirectX; installation of
the game could continue successfully anyway. However, if the game
requires a specific version of D3DX, or other updated functionality
that was skipped, then the game won't work, and the user will be very
frustrated.
So please do as Microsoft recommends, and add the redistributable(s) to your application.
Also do not forget to include the license agreement of any redistributable to your application. These agreements must be presented and accepted by the user before installing.
I have an executable I made using a CLI console application with Visual Basic 2010. I can run the program completely fine from my developer machine.
However, when I copy the executable over to another machine, re-boot to a pre-installation environment and run the executable again, nothing happens at all. There are no errors shown or anything.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
Any ideas on whats going on?
First of all, since the question is tagged "c++" and you mention C++/CLI several times, I assume that "Visual Basic 2010" is a typo for "Visual Studio 2010". But either way, whether you've written the application in Visual Basic (VB.NET) or C++/CLI, the problem is exactly the same.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
That's exactly correct. You've written an application that targets the .NET Framework. Somewhat like Java applications requiring a JVM, .NET applications require that the .NET Framework be installed in order to run (or a compatible alternative implementation, like Mono). Unfortunately, Windows PE does not support the .NET Framework.
Note that it is irrelevant whether you've written a WinForms, WPF, or Console application. Although they present their UI in very different ways, they all depend on the .NET Framework being installed.
You will need to (re-)write the application in a different programming language, one that generates native code without any dependencies on the .NET Framework. C and C++ are popular choices. If you choose to use C++, make sure that you create what Visual Studio calls a "Win32" project. This is one that targets the underlying operating system APIs directly (i.e. a native application) and does not have a dependency on the .NET Framework. Stay away from anything that has ".NET" or "CLR" in its description.
I don't really have a full comprehension of when an application is using .NET or not... I am just used to Linux C/C++ development. I hate Microsoft shit
It uses .NET whenever you use the .NET Framework libraries/classes in your code. I'm not really sure why this is so difficult to understand. The same problem could easily exist on Linux if you were using a third-party library that was not available in certain environments for whatever reason. This is not Microsoft's problem, it's an issue of using the wrong tools for the job. The .NET Framework is an object-oriented wrapper around the native APIs that makes it much easier for people to get up and running writing programs for Windows. But if you're "used to Linux C/C++ development", you should have little trouble writing a simple console application that targets the native APIs directly without using .NET.
If your hatred for "Microsoft shit" has turned into an allergy, you can avoid Visual Studio entirely and download MinGW, which is a Windows port of the GCC compiler you're probably used to. Combined with your favorite Windows port of Vi, you're working in an environment very similar to the one you're used to. And since GCC doesn't support C++/CLI or the .NET Framework, you won't have to worry about getting stuck picking the wrong option.
The .Net framework has been supported as an optional package install during your PE build process for the past couple versions of WinPE. I write code in C# that I run in WinPE everyday. I have yet to find a good way to debug in a manner where I can walk through break points, etc... though. My best option has just been a lot of logging and a global Exception catch around my main entry point that will write out a full stack dump. You can attach to your app as a remote process in a VM running WinPE, but if you need to catch something early in the execution you'll have a difficult time.
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.