For some reason(about the digital signature of the desktop bridge app, see here), I can't use visual studio to package my project. Makeappx seems to be able to do this, but those commands are too complex for me. Is there an easier way to achieve this?
Or to put it another way, how can I directly refer to the EXE file (which I can sign) rather than just the project in the application package project?
If Visual Studio is too complicated I recommend you get the free Express edition from Advanced Installer.
In the link include you can find a video that shows how to build an MSIX package (for bundle just change the radio button option from Builds page).
Additional info -
Publishing an MSIX package in the MS store.
Disclaimer: I work on the team building Advanced Installer.
We have developed a C++ library that does a little bit of data interpretation, mostly converting raw byte streams into JSON strings and also collecting raw data packages and returning the collection as a binary file (byte stream).
This library is written with pure C++ STL without any other libraries as dependencies and is used successfully in Android and iOS projects.
For a new C# project for Windows Desktops, developed by external partners we have built, a PIMPL class in C++/CLI that enables easy integration of the already existing code base. In Visual Studio we compile the C++ library into a static library with clang/LLVM and use it in the Visual C++/CLI Wrapper project as a dependency to build a DLL that we provide for our partner.
This setup took a little time but it works now fine and we are really happy about the development.
But when we tried to get a Demo running on a different PC we encountered serious problems: It is not possible to load this DLL on a "clean" system. When trying to load it in our application (or a DLL Dependency Walker for that matter) it throws a
After some hours of experimenting I've narrowed it down to the Windows 10 SDK that seems to be necessary to load this DLL.
My guess is that it has something to do with some compiler/linker setting in Visual Studio, but I have no idea which one...
Edit:
All VC++ redistributables (2010-2017, x86&x64 just to be sure) as well as the .Net Framework 4.7 and .Net Core Redistributable are installed.
Windows SDK 7.1 was the last version that included the baseclasses direct show sample. But later Windows SDK have strmbase.lib with the compiled library. What use is the library without the headers?
It might be included without good reason waiting for its cleanup time, or there is unobvious reason such as reference to this static library when linking other legacy libraries.
Either way you are correct in the part that DirectShow bases classes are no longer in Windows SDK. Those interested in DirectShow development would typically get DirectShow BaseClasses and samples from Windows-classic-samples/Win7Samples and build the code including strmbase.lib themselves.
I am not a full time programmer, but have to do a little bit to build tools to support my job. I have finished writing my application which I now need to deploy.
I do not want to use "ClickOnce" as I need to alter files in the 'local' folder at configuration time. My understanding is that if I use the Publish option under the Build menu, then I am using "ClickOnce".
My research has led me to believe that "You do this by adding one or more deployment projects to your solution". MSDN then states, that to acheive this I need to select 'Add Project' and "In the resulting Add New Project dialog box, select the Setup and Deployment Projects folder."
The problem is, I do not have such an option ?!
Can someone shed some light on why this would be the case, and how I go about fixing it. I have spent half a day googling and cannot come up with a way forward?
Details of Project and System are as follows:
Environment: Visual Studio 2012 Express for Windows Desktop.
Current Project: Windows Form Application.
Op Sys: Windows 7 Professional.
Correct though its advice may be, that is an old tutorial that you're reading. It is probably referring to Visual Studio 2010.
That option has been removed in VS 2012. You will need to use an alternative tool to build your installer. For example:
WiX
Inno Setup
InstallShield
…etc.
I strongly suggest looking at Wix#. See http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX. If you are doing your coding in C#, Wix# this would probably be the most simple and comfortable skill set to add, and it is free and would directly integrate into the Visual Studio environment you are using.
More info at the CodePlex home page for Wix#: http://wixsharp.codeplex.com/
For C# developers needing to create a Windows Installer MSI to deploy their app, Wix# is perhaps the best replacement for the "Packaging and Deployment" project type that Microsoft removed from Visual Studio starting with VS2012. Wix is a C# front end for the WiX (Windows Installer Xml) Toolset. Using Wix# allows building a complete Windows Installer MSI in the C# language.
Wix# is useful for a broad range of installation/deployment scenarios, and lends itself reasonably well to Continuous Integration scenarios. There are Wix# examples for deploying Windows desktop applications, for installing Windows Services, and installing ASP.NET websites, and many more types of installations.
The question mentioned a need to install applications on Windows 7. Wix# supports this environment, and handles typical installer requirements, and the Wix# installer code for simple projects is indeed simple. For application installs that are more complex, and require advanced features, Wix# can tap into the power of the full WiX Toolset when needed. For example, when installing a .NET application, a typical requirement would be to install the application exe and dll files, and tailor some .NET configuration files and/or registry entries on the target system.
Below is an example of the C# code for a simple Wix# installer that installs an application on a target system, and modifies some configuration files. This example assumes that you have written a utility named "TailorMyConfig.exe", e.g., a simple C# program that uses ConfigurationManager.AppSettings routines, and you are deploying this exe along with your app.
using System;
using System.Windows.Forms;
using System.Diagnostics;
using Microsoft.Deployment.WindowsInstaller;
using WixSharp;
class Script
{
static public void Main(string[] args)
{
var project = new Project("MyProduct",
new Dir(#"%ProgramFiles%\My Company\My Product",
new File(#"Files\Bin\MyApp.exe"),
new File(#"Files\Bin\TailorMyConfig.exe")),
new ManagedAction("UpdateConfigFile"));
project.Id = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);
}
}
public class MyCustomAction
{
[CustomAction]
public static ActionResult UpdateConfigFile(Session session)
{
if (DialogResult.Yes == MessageBox.Show("Config file update ready to run.\n Update config file(s) now?",
"Config Tailoring Utility",
MessageBoxButtons.YesNo))
{
Process.Start("TailorMyConfig.exe", "Run utility to tailor config file to current system");
}
return ActionResult.Success;
}
}
Note that there are "better" ways to modify a config file using WiX XML features. For simplicity, the example above assumed a custom-written C# exe utility for modifying config files. I would suggest using WiX XML capabilities for doing this instead. You can incorporate nearly any WiX XML capabilities directly into your Wix# setup using the Wix# technique of "XML injection".
Remember, Wix# is simply a C# front end that emits WiX XML syntax. After Wix# has emitted the WiX XML (wxs file), that wxs file can easily be post-processed to insert additional WiX XML features. Then the resulting wxs file gets compiled by the WiX Toolset into an MSI.
For an example of using XML Injection to incorporate WiX XML features into a Wix# (C#)installation, look here In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
In that question, see my answer that uses the technique of hooking up a delegate to the "WixSourceGenerated" event.
You could then use this XML injection approach to insert some WiX XML into your installer that would accomplish the config file editing. An example of some typical WiX XML to modify config files is here:
How to modify .NET config files during installation?
Another typical requirement of an installer would be to add or modify Windows Registry entries on a target system. Wix# provides direct support for that using the "RegValue" class. The advantage there is when using Wix# you also get a full "uninstall" capability for free, including uninstalling/reverting registry entries to the pre-install state. This is a natural result of Wix# being built on top of the WiX Toolset and Windows Installer technology. An example of a registry-only Wix# installer is here: In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
The Wix# approach has been very useful in my environment, and it allows use of the familiar C# skillset without having to jump headfirst into the full complexity of the WiX XML installer technology.
I am looking to provide a better way of managing the distribution and storage of binary dependencies for a large VC++ project.
Currently we have the situation where externally and internal built libraries are stored within the the source control repository resulting in the .cpp and .h files forming less than 3% of the space that is retrieved. This makes the process of creating a branch slow, and prevents sensible migration to a DVCS.
I don't want to change the main method of building through MS visual studio solutions, but I am willing to add an additional step to fetch/setup all the binary dependencies.
This is currently achieved for some libraries using are existing Source Control, by mounting different repositories containing the built files. This could be one approach (which I don't favour).
Has anybody got experience of using Ivy or Maven in a VC++ environment?
The maven-nar-plugin might be solution for you.
Maybe vcpkg is a alternative solution for you.
Documentation is available here or for Visual Studio here