I'm writing an UWP Store app that calls other executables, such as OpenSSL and FFmpeg.exe. I successfully included those in a WPF app. However, with UWP, how to build them into the final package to upload to the Windows Store?
I'm thinking of these solutions:
Add the needed file (for example, FFmpeg.exe) to the project. Then chose the Build Action property to 'Content' and copy to Output Directory. But this option seems not possible with the whole folder with sub-folders and files in them (for example, OpenSSL portable folder).
Write a method to copy the file (FFmpeg.exe) into the Local Folder of UWP app when the program starts.
...
Is there a better way to do this? Thanks.
You have to leverage the build powershell commands.
1 Step, Setting up
Go to your Solution Folder, and create a new Folder Called "MyExeFolder"
inside that folder put your desired .exe, like FFmpeg.exe
2 Step, Automating
Right click your entry Uwp Project and go to Properties and then go to Build Events
on your the Post Build event commands enter this :
xcopy /y /s "$(SolutionDir)MyExeFolder\FFmpeg.exe" "$(SolutionDir)\UWP\bin\x86\$(ConfigurationName)\AppX\"
If you are building for x64 too, then you also add the same command with x64 instead for x86 too, if you are building the win32 project along and grouping it under the same solution, you have to define the appropriate bin folder.
3 Step Executing
In order to launch win32 apps from uwp you will have to use an a capability called runFullTrust, it is hard to list all the xml modifications you will have to do to the app manifest to enable such feature but once you figure it out, you will have to add this to the Extension node:
<desktop:Extension Category="windows.fullTrustProcess"
Executable="FFmpeg.exe" />
here is more info on how to set up the manifest
Once you pull all this off you can just launch your win32 part from anywhere on your uwp app by :
try {
await Windows.ApplicationModel.FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}
catch (Exception Ex)
{
//failed to Launch
}
As for Further reading, i suggest you visit stefan wicks blog as he has a great wealth of samples and tuts on how to overcome uwp limitations by using .Net native extensibility.
Related
I have finished a very basic application (wpf/c#). The solution is made of 3 projects:
The main project for the app
The Class Library Project to store app resources (images and txt files)
The Setup project which I use to create exe file for distribution to other
machines.
While the project works fine in debug mode when I deploy it using the Setup project and install on the computer I can access the image files from the Library Project (I can see there is a dll file for the library project in the application folder) but it fails to access the text files, complaining the path was not found. This is my very first time I completed the application and attempted to deploy it so am a bit at a loss why the setup does not provide correct references to the text files and yet it seems to work fine with image files which are located in the same library project.
Can someone point me in the right direction where to look at it to troubleshoot?
I have cleaned and rebuilt all projects in the solution. retested in debug mode (works fine). tried to search msdn and StackOverflow but I cannot find any guidance I could use or follow.
I would like to be able to display text from the text files in the released/installed application version the same way it works in debug mode. At the moment it fails to find the relevant txt files.
Finally, I have managed to crack it. Posting the answer for anyone having the same problem.
The issue here was not with the file path, even though I came up with a more clearer technique of building it, see my comments above. The problem was with the way Setup Project in VS2017 was creating a package. It is handling differently images and text files, even though both are in the same Library Project, essentially for text files I had to do the following to get it working:
Open File System in Setup Project
Create the 'Resources' Folder under 'Application Folder'
Set the 'Resource' folder 'AlwaysCopy' property to 'true'
In 'Resources' folder right-click and select Add> File...
Navigate to the folder with the files and select them all (make sure the files are setup as Resources or embedded resources)
Rebuild the Setup Project
.
So summarising I had to specifically tell Visual Studio to build the folder structure in the Application Folder during the install.
Now when I run the installer the text files are included in the package and created during standalone installation. Also included a screenshot below.
I have created a Console Application where I've added Microsoft.AnalysisServices dll. I want this App to be Scheduled for every 30 minutes.
I've Published the Application but when I give setup.exe path in Windows Task Scheduler, the task not runs
When I give the applicationname.exe path from the bin/Debug Folder, the application runs
reference: https://www.c-sharpcorner.com/UploadFile/manas1/console-application-using-windows-scheduler/
but I don't want to carry the project folder to the Production server, I need a single exe/setup file
I have also tried copying application.exe file from bin folder on desktop but it throws exception 'cannot find Microsoft.AnalysisServices', here is the Screen shot:
Please Help
For a (simple) console application, the easiest solution is to use what Microsoft propagated right from the start of .Net: "xcopy deployment".
Depending on your build target (Debug or Release) take everything from the [project dir]\bin\Debug or [project dir]\bin\Release and copy it to a application folder of your choice.
In your Scheduled Task, reference the executable in this application folder.
You can streamline your deployment by adding an automated copy task as a Post-Build task to your project configuration.
You need to copy the whole output folder (publish artifact). You can omit things like the pdb files or xml documentations... You can also use tools like ILMerge to merge dependencies like the Analysis dll into one file, if you really need to.
I've inherited an old .NET MVC C# website. Bundled into the solution is a 'SearchUpdater' program which seems to be some kind of service:
public partial class Service1 : ServiceBase {
It seems to be an application, on properties we see:
Output type: Windows Application
Target framework: .NET Framework 4
This somehow translates to a SearchUpdater.exe file we have on the web server which is run every day. The code deletes a search index text file and then rebuilds it.
Simple, except I need to update the code logic and replace the .exe.
When I do this I can't seem to generate the .exe file any way I try. If I 'publish' the SearchUpdater project I get a local 'setup.exe' file, which, when I run it generates a kind of SearchUpdater 'shortcut' in my start menu which is a
Type of file: Application Reference (.appref-ms)
Location: C:\Users\Me\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\HP Inc
There's no 'target'...
Basically, I can't find a .exe file anywhere to replace the one on our webserver!
Any ideas? I'm a bit lost with this one, how can I generate a .exe, and will I need to do this somehow on the webserver? Am I doing something wrong?
Thanks to suggestions by #codecaster and #hans-passant. If you build the project in release mode, then go to the solution folder and check in the correct bin folder there is indeed a 'release' folder that will contain the .exe file (or did for me!).
I recently took charge of a new system, it is a windows application written in C#, an installer (.MSI) file is created for its distribution. When I install the software it installs properly but it crashes on start. Then if I run the .exe file once for the application, the installed software starts working.
My observation is that .EXE installs some missing bit which is required by .MSI file. Is there a way I can find what files are missing in .MSI file ?
UPDATE on 09-08-2014:
I have found WER4A29.tmp.WERInternalMetadata.xml file which talks about System.Net.WebException
-<ProblemSignatures>
<EventType>CLR20r3</EventType>
<Parameter0>test.exe</Parameter0>
<Parameter1>1.0.3.33</Parameter1>
<Parameter2>53dca4f6</Parameter2>
<Parameter3>System</Parameter3>
<Parameter4>4.0.30319.18408</Parameter4>
<Parameter5>52311185</Parameter5>
<Parameter6>21b0</Parameter6>
<Parameter7>1fb</Parameter7>
<Parameter8>System.Net.WebException</Parameter8>
</ProblemSignatures>
First run an admin install via command line (cmd.exe) to extract the files from your MSI:
msiexec /a File.msi
Then inspect the extracted files to determine if there are configuration EXE files that perform configuration tasks. Determine what configuration files are there, if any. For example INI or XML files. Check for per user / user profile files.
In case you don't have the tool to view the MSI file, get hold of Orca or install a trial version of a commercial packaging tool. You will need this to see what is happening inside the MSI file. If you list the content of the Custom Action table there may be clues there as to what is going on. Also look in the Registry table for per user data to go into the registry. Debugging an MSI properly takes a lot of domain knowledge, but looking through it like this is useful too. Just post follow-up questions. I assume you have the Wix source code too?
To debug the application launch use Process Monitor (procmon.exe) to determine what is going on during the successful launch. The logging is a bit verbose, but with flags you will get to narrow it down.
- For native applications (Win32, or non-.net), I like to use Dependency Walker (depends.exe) too. It can be used for .NET too, but I find it less useful. I am not aware what the best dependency scanner for .NET is at the moment.
If manual debugging fails, several tools used for application repackaging are able to scan the system and determine the state before and after something is done and capture it as a list of differences. Advanced Installer's trial version should be able to do this. With some technical insight you should be able to identify what is needed from the diff image.
The .msi file is the installation set-up it include the installation script and the actual executable .exe file and other required dlls and configuration files.
I think the issue is with how the set-up is created. when you start the application after installation it is not performing the start up tasks like configuration of environment.
And the when you run the .exe it takes care of these configruations by it self.
I suggest that the testing of setup files .msi files and its generation scripts should be revisited.
I have a annoying build process from using System.Addins API with ClickOnce. Using System.Addins requires a specific directory structure, and the main project does not reference the adapters, view, and contract directly, which doesn't work well with the ClickOnce architechture.
The annoying part with the build process is that I have to copy, via post build event, the .dlls from the add-in components into the directory of the main app project, then reference those files manually from the main project, so that ClickOnce will include them. Firstly, this takes 2 iterations of build to get it to build correctly, secondly, it interferes with source control (I have to exclude the copied add-in dll files from source control or any changes made to them would require checkout).
So, my question is, is there a way around this hack? Something more elegant?
I can't fully answer your question, but it appears you are creating ClickOnce deployments through Visual Studio. I would ditch that method and use MageUI instead. It's a stand-alone executable that can be found in the framework SDK that will generate your application and deployment manifest files. It comes with a gui version (mageui.exe) and a command line version (mage.exe).
Mage may not get rid of your post-build event but it should do away with having to reference the files to get ClickOnce to see them.
Thanks for your input, I am currently doing it the way you mentioned; creating the folder in my project, and include the dlls that I need. It works, but it's an ugly solution, and it interferes with Source Control.
I'm aware of the limitations of ClickOnce, I was hoping there may be a way around it. For example, I read somewhere that I can use deployment projects to create the appropriate dependencies needed in a specific structure. The problem with that is once it is deployed to the public, there is no easy way (within ClickOnce) to update those dependencies.
The solution I use is to have a single output folder for all projects. Every project puts it's own files in the correct subfolder. The application bootstrapper project puts his dlls also in the output (root) folder. When you then create a click-ones for the bootstrapper, it will take all the content from the output folder.
The hardest part is to actually get all the dll's in the right place (and have every dll only once)
I solved this problem by adding the pipeline assemblies as content into the main solution structure.
To do this, change the output folder from (/bin/debug /bin/Release) to something else. I used ../lib otherwise you would get a visual studio cannot reference this file error.
Create the pipeline folders in your main solution
\AddInSideAdapters
\AddInViews
\Contracts
\HostSideAdapters
Right click on each of the folders and click "add existing item" change to view all files and then browse to your ../lib (or wherever you have the output set) and then pull down the add button (click the down arrow) and click "Add as a Link".
Right click on each file and set it to Content.
This will create a refresh file pointed to your assemblies and they will be included into the clickonce manifest.
ClickOnce do not let you install the software where you want. It will install the binary and dlls in the documents and settings. You can in your project properties go in the Publish tab and select Application Files to select additional file to Include. If the System.Addings require dll in a specific folder relatively to your assembly, you might just create the folder in you project and includes from here the dlls. This might works. If not, I do not have "hack" or other solution, clickonce is great but limited with some functionalities.