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.
Related
I've been trying to figure out on how to setup a Cross-Platform project for MonoGame. Whats the conventional way of doing so ?
Is that done through a Shared Project and can I keep all my content in 1 project ?
Also I am not sure if this information is correct do I need a Mac to build my project for Mac how does that work ? If so how what's the best way of setting that up.
Targeted Platforms : WINDOWS, LINUX, MAC
The best way to setup a cross platform MonoGame project IMO would be to use a Shared project. Shared projects can also include .mgcb file so you won't need to duplicate your content either. How to do:
Use "Xamarin Studio/MonoDevelop" and create a "MonoGame Shared Project" with the name of your game
If you are going to use using "Visual Studio", close the "Xamarin Studio/MonoDevelop" after this, and open up the created project vith it
you are gonna have to include the generated "Content\Content.mgcb" file with build action "None" so it will be visible in Project View area
Add a MonoGame Project for the platform you wish to launch the game from, ie. create a "MonoGame Crossplatform Project" and name it "(gamename).DesktopGL"
Delete "Game1.cs" and "Content Folder" from the Platform project
Add a reference for your Shared project
For your platform project, in options set the Output Assembly Name to be the same as your shared project
this step might not seem important, but if you are using a custom importer/processor this will allow you to not have to compile the content separately for each platform.
There you go, you should be able to run your project now.
Also I am not sure if this information is correct do I need a Mac to build my project for Mac how does that work ? If so how what's the best way of setting that up.
The created executable from DesktopGL project is runnable on Mac even when compiled from Windows, the Mac user just has to launch it using Mono. In case you want you can package your game using MonoKickstart so that your Linux and Mac users don't have to have mono installed: https://github.com/MonoGame/MonoKickstart what's more, it also includes other needed native libraries. Description on how to use it are in the link.
Since you're just targeting Windows, Linux and Mac, you can use Xamarin/MonoDevlop which runs on all three of your target platforms.
Once it's installed, then add the Monogame through the Addin manager. The addin on version 5 of Xaramin and MonoDevlop.
You can then use the same Solution project file between all three platforms assuming you use the OpenGL Template. I use this method for developing between Windows and Linux.
The only time you'll need to use a shared project or something similar would be if you started developing for Mobile (iOS/Android) or for Windows on DirectX instead of OpenGL.
I have a problem. I recently installed VS 2015 and Windows 10 on my computer.
Having Universal Apps are amazing and I plan to convert some of my programs on UWP.
But I have a problem. In one of my programs, I allow the user to save its datas on its OneDrive. And if OneDrive is unavailable, the datas are stored on local devices.
And when OneDrive is available, the newly stored datas are pushed to OneDrive. Synchronisation in fact.
So it is the problem. In the UWP dll named Universal.Live I have installed Live SDK 6 with Nuget. During the package installation, there is some work done to see if the Live SDK is compatible with UWP.
Great ! It's compatible and successfully installed.
But when I wrote
using Microsoft.Live;
The name is not recognized. And if I use the class LiveAuthClient which is in the namespace, it isn't recognized too...
This is a real problem :( Any ideas ?
I had the same issue adding the Live SDK to my app. For some reason the Package.JSON isn't correctly resolving and downloading the package (or recognizing it).
Either way, just add the DLL to your references the old fashioned way. Personally, I'd just add it to a console app (not using the new Project.json package), get it from NUGET, and grab the DLL from the Packages.
After you have the DLL:
Right click on References
Add Reference -> Browse...
Find the DLL and add it. ("...\\packages[LiveSdk]...")
It works!
Download it from here, Compile it, and grab the desktop SDK:
https://github.com/liveservices/LiveSDK-for-Windows
You can also download the msi, install it, figure out where the DLL is installed to and grab it from there:
https://www.microsoft.com/en-us/download/details.aspx?id=42552
According to this GitHub issue, LiveSDK isn't supposed to be used for Universal Windows Platform apps: https://github.com/liveservices/LiveSDK-for-Windows/issues/58
Instead we should use these SDKs that cover the same functionality:
Mail/Calendar/Contacts: https://dev.outlook.com/
Files/OneDrive: https://dev.onedrive.com/
I've downloaded Crashlytics app that integrates Crashlytics.framework into XCode project, and it works great for XCode. But as far as I know, to build Xamarin.iOS binding I need static library, and I can't find it neither in framework nor in Crashlytics.app contents. There is only "run" executable and header. I don't know how to use it under Xamarin.iOS. Btw, AndrewReed on Xamarin forum managed to build dll somehow, so it's possible.
So, how to create crashlytics binding for Xamarin?
AndrewReed answered this question on Xamarin forum:
As with quite a few sdk's, sometimes they bundle a folder instead of the static lib,which essentially is the static library. There will be a sizeable file that maybe doesnt have an extension(this is your .a file) so you can rename that to be .a and then include that in a xamarin bindings project. Run the sharpie marker on the header file in the folder which will generate your necessary files. Watch out for one gotcha, delegate is a reserved word in c#, so you may need to go around and change this by adding an # symbol(to the name) to allow you to use the reserved word.
So what I actually did was, created a project in xcode and ran the crashlytics programme, this then added the crashlytics framework to the project. In finder locate that and you will have a structure like so: - run - /Versions --/A ---Crashlytics ---/Headers ----Crashlytics.h
So the /A folder is essentially your static lib, use this and create your binding from that, or in this particular case, just download it from the mono bindings || my repo.
If you're looking for an officially supported crash reporting plugin, Crittercism just released one (Full disclosure: I'm one of the co-founders). You can download the bindings from the Xamarin store here: http://components.xamarin.com/view/crittercism
The latest version of Xamarin seems to have it build in.
Here are the steps that I followed
1.) In the Xamarin Studio , go to the main app, and add the Crashlytics API key in the Build -> Crash reporting section. Build and run that app. The evidence suggests that is enough to get data sent to Crashlytics. I saw that it knew about older versions of the app I had built and ran weeks ago with the API key already in.
2.) Go to Xcode and create a new project with the same name as the Xamarin project, com.{company}.{appname}. (You probably need to have that profile downloaded.) I did it in Swift by the way with no issues.
3.) Go to crashlytics.com com and go to settings -> Apps (or https://www.crashlytics.com/onboard)
4.) You will get an app to download and run. The app walks through the steps of adding
A.) A build phase run script
B.) Code to the application main Crashlytics.startWithAPIKey(“nnnn”)
5.) Run your Xcode version of the app
The Crashlytics web page popped up immediately.
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.
If I have a version of Orchard installed on a server via Microsoft Web App Gallery from my hosting provider, Is there a good way to pull down the instance of orchard for local visual studio development?
When doing Visual Studio development, always use full source from Codeplex. The WebPI package is intended to use out-of-the-box when you don't want to perform any coding.
In your case it's quite tricky, though, but doable. The best approach would be to
Grab the full source as described here,
Grab the source from your server
Copy the files from 2. to src/Orchard.Web subdirectory found in 1. (overwriting any existing stuff)
Open up the /src/Orchard.sln solution in VS and add references to any custom modules you had on your server (2.) that are not in the Orchard core (1.). You will find those under the /src/Orchard.Web/Modules subdirectory.
I'd go with Piotr's answer, but if you just need to make some tweaks then the code from WebPi should work okay with WebMatrix.
I wouldn't use this solution for module development, but if you just want to tweak a simple theme or run the site locally then it's worked for me.