android.apk file not being generated in Visual Studio 2017 - visual-studio-2017

After upgrading to VS 2017 15.6, when I build my Ionic 1.3 / Cordova project, in "Release" configuration I no longer get a file named android.apk in the bin\Release folder. Instead I am getting a file named VSBuildInfo.xml.
I used to use the android.apk to deploy to my device. How do I do that now?

Something has changed and it's now working as long as I select "Device" as the target.
I don't remember having to select "Device" as the target when building in previous versions and I was pretty sure that when I was building in "Release" configuration that I did have it selected as the target - but I could be wrong about that.
One thing I did do was connect a device and click "Deploy" instead of "Build". So it is possible that doing that triggered something that made it start working. This could be a red herring, because it is now working consistently.
If I select "Simulate..." instead of "Device" as the target, then I get a VSBuildInfo.xml file instead of an apk, as described in my question.

Related

use devenv to generate ispac with EncryptSensitiveWithPassword

We have an external app that allow use to build and deploy ssis projects using command tool
after a migration with vs 2019, process no longer work (probably because external app use old resource file)
previously, we use msbuild, with a xxx.proj using
UsingTask TaskName="DeploymentFileCompilerTask" AssemblyFile="C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.SqlServer.IntegrationServices.Build.dll"
now, the same no longer work. I tried to use a newer version of Microsoft.SqlServer.IntegrationServices.Build.dll but it refer now to an vsintegration dll file.
So, I would like to use devenv.com tool instead.In local, it works.
the problem is that some projects have SecurityLevel to EncryptSensitiveWithPassword and when using
devenv.com "project.sln" /Build Development /Project "project\SsisCommon.dtproj" /ProjectConfig Development
in local, it prompt for the project password, and then after entered it, it generate ispac.
But the problem is that the external app not allow prompting, and then we got this kind of error
Unhandled Exception: System.InvalidOperationException: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.
How I can pass the project password without prompting ?
thanks in advance
regards
I finally use the SSISBuild project - https://github.com/rtumaykin/ssis-build/ - (recompiling after updating encrypt / decrypt process) as related here: https://github.com/rtumaykin/ssis-build/issues/25
it works finally fine.
regards

VS2019 + Xamarin.Forms = UWP/EXE dropped?

How do I get the UWP back into Xamarin.Forms Cross-Platform creation to have the templates ready to roll?
After picking through the release notes, playing with VS2019's UI and a few hours of web searching, I have only found others posting about the problem in the preview versions. Some say UWP is gone forever, some say it just isn't included by default (so Microsoft can brag about how the install went from 23GB to 8GB or something like that) - but no help on HOW TO re-enable it, or add it to the project creation wizard (apart from adding a blank UWP project sans all code that is in the iOS/Android projects).
<Project Sdk="Microsoft.NET.Sdk">
// the code is not the problem here,
// getting TO the code is the problem
</Project>
EXPECTED:
In VS2017, Xamarin.Forms Cross-Platform supplied iOS + Android + UWP templates by default.
ACTUAL:
Visual Studio 2019 seems to have removed the UWP template from Xamarin.Forms Cross-Platform project creation.
Update 9 apr.: a new version of 2019 was released which reinstates the UWP templates again
It is correct that the UWP template is removed from VS2019, I don't know the reason behind it, but we'll have to deal with it. There is however a page that runs you through the process step by step. It has been there for a while for the projects that were created in Visual Studio for Mac, which don't include the UWP template as well. The full description can be found here: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/platform/windows/installation/ taken from this page:
First, right-click on the solution and select Add > New Project... and add a Blank App (Universal Windows) project:
Then, select the minimum and targeted UWP versions.
Right-click on the UWP project and select Manage NuGet Packages... and add the Xamarin.Forms package. Ensure the other projects in the solution are also updated to the same version of the Xamarin.Forms package.
Also, make sure the new UWP project will be built in the Build > Configuration Manager window (this probably won't have happened by default). Tick the Build and Deploy boxes for the Universal project:
Right-click on the UWP project and select Add > Reference and create a reference to the Xamarin.Forms application project (.NET Standard or Shared Project).
In the UWP project, edit App.xaml.cs to include the Init method call inside the OnLaunched method around line 52:
// under this line
rootFrame.NavigationFailed += OnNavigationFailed;
// add this line
Xamarin.Forms.Forms.Init (e); // requires the `e` parameter
In the UWP project, edit MainPage.xaml by removing the Grid contained within the Page element. Then in MainPage.xaml, add a new xmlns entry for Xamarin.Forms.Platform.UWP, like this: xmlns:forms="using:Xamarin.Forms.Platform.UWP".
In MainPage.xaml, change the root <Page element to <forms:WindowsPage, like this:
<forms:WindowsPage
...
xmlns:forms="using:Xamarin.Forms.Platform.UWP"
...
</forms:WindowsPage>
In the UWP project, edit MainPage.xaml.cs to remove the: Page inheritance specifier for the class name (since it will now inherit from WindowsPage due to the change made in the previous step)
public sealed partial class MainPage // REMOVE ": Page"
In MainPage.xaml.cs, add the LoadApplication call in the MainPage constructor to start the Xamarin.Forms app:
// below this existing line
this.InitializeComponent();
// add this line
LoadApplication(new YOUR_NAMESPACE.App());
Add any local resources (eg. image files) from the existing platform projects that are required.
And now it should work as before. I know, it's a hassle to go through it for something that just worked before. Sorry about that, but this should get you there as well.
With the Update 16.0.1, Microsoft restored the UWP creation on new Xamarin.Forms applications
except when you try to use Shell, which is not available for UWP:
Issues fixed in Visual Studio 2019 version 16.0.1
Add option for Windows (UWP) platform when creating new Xamarin.Forms project from 'Mobile App (Xamarin.Forms)' project
template.
EDIT (7/17/2021): i have started a new xamarin forms solution and it seems all 3 platforms are available again in VS2019 on all prebuilt templates (blank, master-detail, tabbed layout).
thank you, everyone, for your input.
great information!
it helped me steel myself to face the fact:
UWP is gone (for now) from Xamarin.Forms new project scaffolding.
but, the (simplest) solution to the question asked that i have found is:
open VS2017. create new Xamarin.Forms cross-platform project.
once it is open, save-all.
then close VS2017 and open in VS2019 if so desired.

Your project is not referencing the "UAP,Version=v10.0.10240" framework

I am using Visual Studio Community Edition 2017 and trying to create a UWP application.
I get the following error
Your project is not referencing the "UAP,Version=v10.0.10240" framework. Add a reference to "UAP,Version=v10.0.10240" in the "frameworks" section of your project.json, and then re-run NuGet restore.
I had the same issue on my build machine. What's weird is everything runs fine on my local machine.
I managed to fix this by going into the project properties for my UWP app, and changing the Target version to match the Min version.
The reason I believe this issue is happening is because when targeting a higher framework, on a Windows Server machine (the build agent) it doesn't restore all of the packages between your min and target version. It seems to build fine against the version you target.
By the way Ken, following the instructions given by the error don't fix the issue. Try not to be so rude. I came to this page looking for the same issue, and you are no help at all.
I have the same issue, after I remove my bin and obj folder, I can build mine and see the errors gone.
I recently ran across this same issue when updating the target framework. The issue turned out to be the Nuget Restore task in my VSTS Build definition needed to be updated to the latest version (2.*). Once I did that, the builds worked as expected.
I agree with Jeff. Ken Not sure if you should be giving any answers with this kind of attitude.
The error message is misleading there is not project.json at least you cannot see it in the Visual Studio explorer.
I had the same issue and have min and target version set to the same number but it would not build.
The fix was to make sure in Nuget package manager setting to tick checkbox 'Allow Nuget to download missing packages' and the one below it as well and rebuild the project.
This is a pretty weird mistake, but what worked for me :
1st Solution:
1 - Change your project target to "10.0.10586" (or up)
2 - Make a clean / nuget restore / rebuild
3 - Return the project target to the "10.0.10240"
4 - Make a clean / nuget restore / rebuild
Do not ask me why, but it worked :)
2nd Solution:
If you use a repository with Tortoise, try making a CLEANUP
I had an old Backup folder in my project that contained a project.json. Looks like it might have been from an earlier upgrade. I deleted Backup and got a good build.
This happens in exactly this manner, if projects were generated in the year 2017 in the phase where MS changed to project.json and then decided against it. I tried several solutions (and yeah, Ken White is so wrong!) and the cleanest way was to really build up a new clean project in the lastest and up to date version of Visual Studio (VS2015 did not work sustainable) and just copy over the old project content which is just a few minutes work. This will save you a lot of headaches especially working in a larger team!
I tried the above solutions but nothing worked. I had to backup and remove the UWP project and recreate it from scratch.
I tried a couple of solutions.
Solution 1
Open the solution from Windows explorer and search for project.json files. Open all of them (If you have multiple) and make sure the required framework versions are there. I frequently switch between build 10240 and 17763 and I get this error frequently. (I switch between git branches that target different frameworks of UWP) So instead of adding the exact version I just added only the 10.0 part like this.
"frameworks": {
"uap10.0": {}
},
Now if your project.json files are ok, search for project.lock.json files. If you have one or more of those, delete them.
Now clean your solution
Close VS
Delete all the bin and obj folders.
Reopen the VS and try to run the app.
Solution 2:
Go to project properties
Change the minimum and target version to something else and do a clean build. Then put the actual versions and build again.

How do you change kits in Qt to target an x86 machine?

I'm currently working on a project in QtCreator. I'm using a library that is x86 based but my current project is targeting an x64 architecture. The obvious solution is to change my project to target an x86 architecture. However, I have no idea how to do this.
I've gone into the appropriate window to configure a new Qt kit. This kit uses the MVCC x86 compiler. I then select this as my default project. After running the new qmake, I attempt to build the project yet get the same error regarding using a 32 bit library in a 64 bit project.
So my question: how do I apply a new kit in Qt? I assume I should be able to click the 'Open Build and Run Kit Selector'and select the kit, however, this just gives me the options of select the x64 kits.
Any idea?
First make sure the kit is added in the Build & Run menu of the Options panel. I think you have performed this step already:
Then go to the Projects tab after you have loaded your project and click on "Add Kit". There you should be able to select your newly added kit:
Finally, you should then be able to select it from the kit selector:

Cannot add Custom Action in Visual Studio 2010 installer project

I converted a working project from Visual Studio 2008 to VS2010. The c++ solution builds a single executable and 3 DLLs, and a windows installer project.
After converting to VS2010, I received a build error "Unable to build custom action named 'Primary Output from xxxx (Active)' from project output group 'Primary Output' because the project output group does not have a key file."
I removed and re-added the output groups, then attempted to add a custom action. The executable output was not listed as a candidate for a custom action. I then noticed when I selected the executable "Primary Output" properties, that the "KeyOutput" property was set to (None) and was grayed out.
When revisiting the VS2008 version, the KeyOutput property was not grayed out. I found the error message on MSDN, with a useless fix:
"Remove the custom action and replace it with a custom action pointing to a project output group that has a key file."
Obviously the tech writer didn't know how to fix it either. Keep in mind the original build worked and installed correctly. I believe the root issue is why the KeyOutput property is disabled - but why? (When viewing "Outputs" it correctly shows the exe or dll in each project)
I had a similar problem and I figured out why the setup project could not find the key output files.
My project Output Directory was defined as $(SolutionDir)\bin\$(Platform). SolutionDir already has a trailing backslash so the \bin was placing a double backslash in the path. The project would build fine but the setup project couldn't resolve the key outputs. Setting the output to $(SolutionDir)bin\$(Platform)\ resolved the issue.
After further investigation, I found this is a bug in Visual Studio 2010.
If you specify an output name for a project that differs from the name of the project itself, it fails to do the right thing.
To reproduce this, change
Project properties->Linker->General->OutputFile from $(OutDir)$(TargetName)$(TargetExt) to be something like $(OutDir)foobar.exe
The project then changes the KeyOutput value to empty, and is not available for custom actions in installations. No workaround other than living with the default project naming convention.
Very late answer but hopefully it will save someone the 2 hours I spent banging my head on the wall with VS 2010 ( what an awful piece of software it is - slow to load and takes up 300 megs of working memory per devenv , and now this bug!!!!!????) here goes -
Roger Dunn was correct is saying that it is the Project properties->Linker->General->OutputFile that causes the problem - if you have something like $(OutDir)foobar.exe the custom action barfs , if you change it back to $(OutDir)$(TargetName)$(TargetExt) it works again!
The work around is to change the macro $(TargetName) to foobar and then user $(OutDir)$(TargetName)$(TargetExt) if you want custom name for your exe.
$(TargetName) can be changed at - Project properties->Configuration Properties->general->TargetName.
But what a waste of time this VS 2010.