I want to implement windows desktop form application having no dependencies to install (e.g. framework, third-party etc).
In which technology I can achieve this?
Can i achieve this goal in C# Win-forms?
You can build an MFC app that requires no installation (just copying the files to the target computer) by statically linking and/or deploying the Visual C++ runtime redist side-by-side.
As Arnon has answered, you can build a .Net app that requires no installation if you target a version of .Net that is pre-installed on your target operating system. This blog entry lists the .Net versions included with each version of Windows.
what version of windows are you targeting your application to ? different versions of windows have different versions of .NET (see this link for details).
So basically, if you are looking for no installation you'd have to shoot for the lowest common denominator and/or ship multiple versions of your app.
I understand that it isn't what you want but -If you do go with .NET it is usually better to ensure that the installer will install the right version of .NET if needed (see this link for example)
Related
how to create apps for winget using electron.js, I first thought of using portable in target but it just installs the app but I can't use it again, is the any other targets which I can use?
Today, you would need to be able to provide an installer for an electron.js app. The Windows Package Manager supports three types of installers as of the 1.1 release.
MSIX
MSI
.exe installers
Work is in progress for portable applications (just a loose executable like NuGet), and for installers inside of a .zip file. These are targeted for the 1.3 release.
I'm using Fedora 27 as my Operating System, and I'm wondering if I could get the Xamarin toolset working on it to create cross platform apps with an IDE like monodevelop, VS Code or Rider.
I heard Xamarin get's new templates for Xamarin.Forms for Linux, but I can't find any recent development news about that.
Yes, as of mid-2018, it is somewhat possible to develop a Xamarin.Forms app under MonoDevelop on Linux. I successfully managed to do it.
Basically, you need to have at least two things:
A shared library project, containing all the cross-platform Xamarin.Forms code and Xaml files. For some reason, on Linux this library project have to be compiled with .NET Core toolchain and not Mono toolchain (otherwise there is some GTK issues at runtime later on). The target framework is .NET Standard 1.0 or .NET Standard 2.0, and the main dependency is the NuGet package "Xamarin.Forms".
A Mono/GTK# platform-specific project for Linux, containing all the platform specific code: initialize GTK and Xamarin.Forms.Platform.GTK backend, and start the Xamarin.Forms code. The dependencies are the NuGet package "Xamarin.Forms.Platform.GTK", references to locally installed GTK# of your linux distribution (gtk-sharp, atk-sharp, etc...), and obviously a reference to the shared library project. Note that only GTK2 is supported and not GTK3.
The shared library project may be developed with MonoDevelop, Visual Studio, or JetBrains Rider. Note that with MonoDevelop, there is no XAML designer... so this is easier to do the design stuff with Visual Studio on Windows.
The platform specific project may be developed using MonoDevelop or Rider on Linux.
Here is a picture of the project structure under MonoDevelop:
There is a "HelloWorldXamarin" library project. It uses the .NET Core toolchain targeting .NET Standard 1.0, and have a dependency to NuGet package "Xamarin.Forms"
There is a "HelloWorldXamarin_Linux" project. It uses the Mono toolchain targeting Mono/GTK# for Linux, and have dependencies to GKT# and HelloWorldXamarin library, as well as dependency to NuGet package "Xamarin.Forms.Platform.GTK". You can see the platform specific code on the right.
And a picture of the result:
So you can now develop cross-platform Xamarin.Forms GUI applications for Windows,Mac,Linux,Android,iOS...
Yes you can and how well it will work on Fedora I'm not sure, but it looks like development is still in progress for the GTK Backend on Linux. For more information, there's a Github repo here that shows how far along it is and how you can try it yourself.
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
We have a VC++ 2012 application for native Windows (classic fat app)
Also we have a NSIS based installer.
I would like to add the VC110_CRT merge modules to the installer but the merge modules cannot be installed on Windows XP. The error Message is.
This installation package cannot be installed by the Windows Installer service. Your must install a Windows service pack that conatains a newer version of the Windows Installer service.
and yes, Its a fully updated Windows XP (SP 3 + all updates). As far as I understand it, we need at least Windows Vista to install the update.
My Question:
Is there a way to convert the Microsoft_VC110_CRT_x86.msm module, so its usable under Windows xp
I know I can use the vs_2012_redist, but it has ~6,5 MB instead of ~0,8 of the merge modul size.
and I only need the CRT, because the app uses QT and no MFC/ATL/....
This is an incorrect error message. MSIEXEC is looking at the schema verson in the SummaryInformationStream of the MSM and seeing it's newer then the version of MSI on Windows and giving you this error message.
In truth, merge modules can never be installed because they have no concept of Product or Features. They are merely encapsulated collections of components and related installation metadata. Merge modules are like .LIB files in C/C++ and are statically linked (merged) into an MSI at build time.
NSIS isn't a Windows Installer technology so it can't use merge modules. Instead you should use the redistributable provided by Microsoft and launch the EXE with the correct command line.
You're only other options are to deploy the desired DLL privately (in your application directory), statically link it in your EXE or dump NSIS and create a proper MSI.
Be aware of the security / patching implications of your choice.
If I built my app against D3DX June2007_d3dx9_34 and the target system has a newer version Nov2007_d3dx9_36 should that be a problem?
I distribute D3DX DLLs using MS' redist-installer tool but I noticed one one 'clean' PC (no D3DX previously installed) I got an error about missing D3DX DLL. Before trying to figure out if the installer itself is not working, I wondered if maybe supplying a too-new version of the DLL is the problem - will the app be looking for a DLL with the exact name?
D3DX libraries are not backwards-compatible, and the API may change between versions. So the target system must have the same version of D3DX that you build your application with - a newer version won't work.
If you use Dependency Walker on your application, it should show you that there's a dependency on a DLL with the exact version number.
The redistributable in the DirectX SDK includes the whole history of the D3DX dlls. Installing the latest version of the DirectX redistributable should have your system end up with every version of these dlls. It is possible and allowed for applications to only install the files they need by deleting cab files out of the redistributable's directory structure, in order to reduce the size of the redistributable components, and this is how you can end up with having 43 of the dll but not 37 for instance.
If you remove the dependency of D3DX and D3DCOMPILER dll's from your application you can ensure the application will work as the d3d9 d3d10 and d3d11 core dlls are version-agnostic and are also tied to the windows service pack releases (i.e. D3D11 for Vista comes from Vista SP2 or Win7 stock installs for example).
Another possible way to remove the dependency and let the app startup is to make the dll a delay load module, so it is only loaded when needed (such as compiling shaders on a development environment). As long as you are sure the shaders exist on end-user machines properly it won't need to compile shaders and won't crash. Calling LoadLibrary and invoking the functions manually would be a safer choice with a way better error message of your choosing, but is a lot more work.