Unable to install Android apk from AppCenter - ibm-mobilefirst

I have an ant script that builds&deploy a MFP app for android (wlapp and apk). I also upload the app to AppCenter.
The problem is that I cannot install (on a device - Huawei P6) the apk from the AppCenter using the AppCenter app - it downloads the app but the installation is not successful. The uploaded app is not signed.
Running the Android app from the MFP Studio works fine.
What steps do I have to perform in order to make the installation from AppCenter app work? Where can I see the logs from AppCenter?
Thanks!
Ant target:
<target name="build-android-windows" if="isWindows" description="Build the Android .apk" depends="">
<!-- These must be set in your local.properties file in the root of the android project.
This is sensitive information and is not checked into the repository
<fail unless="android.store" message="Property android.store missing" />
<fail unless="android.alias" message="Property android.alias missing" />
<fail unless="android.store.password" message="Property android.store.password missing" />
<fail unless="android.alias.password" message="Property android.alias.password missing" />
-->
<!-- use android.release_target if defined, otherwise default to 'release' -->
<property name="android.release_target" value="release"/>
<!-- call the project's build.xml to clean -->
<ant antfile="${src.dir}/apps/${curBrand}/android/native/build.xml" inheritAll="false" useNativeBasedir="true" target="clean"/>
<!-- call the project's build.xml to make a build -->
<ant antfile="${src.dir}/apps/${curBrand}/android/native/build.xml" inheritAll="false" useNativeBasedir="true" target="${android.release_target}" />
<!-- copy the file to build.dir -->
<copy file="${src.dir}/apps/${curBrand}/android/native/bin/${curBrand}-${android.release_target}-unsigned.apk" tofile="${build.dir}/android/${build.apk}" overwrite="true" failonerror="true"/>
</target>

As Vivin suggested in the comments, the AppCenter is not Google Play meaning it is not a "trusted source" at least from the device's perspective, thus you may need indeed to enable that option in Android's options.
The second option is as I mentioned - to sign the .apk. When you build directly from Eclipse it uses debug signing by default and goes straight into the device.

Related

DotNet Core 2.0 WebDeploy call to npm build not working on Publish

I have in past used a strategy whereby our backend devs work in VisualStudio and our UI guys work purely in Sublime/VSCode etc. During website publish in VS2017, I used a publish target to first run npm install, then npm build (to bundle our app.js logic), then include that front end content into the backend package for WebDeploy.
I am trying to replicate this in a dotnet core 2.0 project, but the publish target calls to build the front end are never called (ie you never see the echo command content, nor does the npm install / build run)... so no UI resources are included when the publish happens unless i had previously manually run the build process to generate them from VSCode and they already exist on disk. Ie. the COPYING of the UI generated files works great (if they exist)... but VS2017 is never calling the npm commands to BUILD the resources?
While a touch fiddly, this works great in several .NET 4.6+ projects. I have just copied that exact same logic to a Core 2.0 project, and for some reason it isnt working the way I expect? Any ideas?
E.g. my ProjectDeploy.pubxml file contains (at the bottom before the final closing 'Project' tag):
<!--
make sure that we BUILD the UI *before* we copy the files to the package
See: http://byalexblog.net/using-msbuild-to-deploy-composite-web-application
See: http://www.codecadwallader.com/2015/03/15/integrating-gulp-into-your-tfs-builds-and-web-deploy/
-->
<PropertyGroup>
<!-- relative path back out of 'current' folder to outside location of the UI files -->
<FrontEndLocalPath>..\..\src-app</FrontEndLocalPath>
</PropertyGroup>
<!--
Build the mobile web app assets , ensuring that all packages are installed and up to date
-->
<Target Name="BuildFrontEnd">
<Exec Command="echo Got Here also Dale" />
<!-- requires that NPM be installed in environment variables, which we will assume rather than use the NPM env variable above -->
<!-- call npm install -->
<exec command="npm install" WorkingDirectory="$(FrontEndLocalPath)" />
<!-- Run npm run build to populate the www folder with your latest minified production build. -->
<exec command="npm run build" WorkingDirectory="$(FrontEndLocalPath)" />
</Target>
<!--
On each package and/or deploy (because they are different), we want to ensure that we bundle up all the Angular dist code and include that as part of the package / deployment.
See: https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/visual-studio-web-deployment/deploying-extra-files
-->
<Target Name="CustomCollectFiles" DependsOnTargets="BuildFrontEnd">
<Exec Command="echo Got Here Dale" />
<ItemGroup>
<_CustomFiles Include="$(FrontEndLocalPath)\www\**\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>wwwroot\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>CustomCollectFiles;</CopyAllFilesToSingleFolderForPackageDependsOn>
<CopyAllFilesToSingleFolderForMsdeployDependsOn>CustomCollectFiles;</CopyAllFilesToSingleFolderForMsdeployDependsOn>
</PropertyGroup>
Okay, so I don't know if this is specific to new dotnetcore 2.0 or not, but I followed these links and got things working perfectly. Working from the inbuilt VS2017 SPA templates, I now no longer follow the approach we used in .NET 4.6 to modify the .pubxml publish profile to attempt a build/copy files.. instead the gulp/webpack build-SPA-and-copy-files-on-build logic is included in the .csproj file. Note that the benefit of this is you can BUILD your solution quickly without building the UI each time, but still bundle up all fresh UI changes on deployment. My working example follows link:
https://stackoverflow.com/a/44429390/4413476
<PropertyGroup>
<!--
relative path back out of 'current' folder to outside location of the
custom single page app UI files (and any other paths we require)
-->
<FrontEndLocalPath>..\..\src-app</FrontEndLocalPath>
</PropertyGroup>
<Target Name="DebugBuildSPA" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('wwwroot\dist') ">
<!-- Ensure Node.js is installed -->
<Exec Command="node --version" ContinueOnError="true">
<Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
</Exec>
<Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
<!--
In development, the dist files won't exist on the first run or when cloning to
a different machine, so rebuild them if not already present.
-->
<Message Importance="high" Text="Performing first-run Webpack build..." />
<exec command="npm install" WorkingDirectory="$(FrontEndLocalPath)" />
<exec command="npm run build" WorkingDirectory="$(FrontEndLocalPath)" />
</Target>
<Target Name="PrepublishScript" BeforeTargets="PrepareForPublish" Condition=" '$(IsCrossTargetingBuild)' != 'true' ">
<!-- Build our single page application content -->
<exec command="npm install" WorkingDirectory="$(FrontEndLocalPath)" />
<exec command="npm run build" WorkingDirectory="$(FrontEndLocalPath)" />
<ItemGroup>
<Dist Include="$(FrontEndLocalPath)\www\**;" />
</ItemGroup>
<Copy SourceFiles="#(Dist)" DestinationFolder="$(PublishDir)\wwwroot\%(RecursiveDir)" SkipUnchangedFiles="true" />
</Target>

MFP CLI cannot build-deploy project initially created with MFP Studio

Problem Context:
We initially created a MFP hybrid project with the iOS environment using MFP Studio plugin for Eclipse. We have this project under source control (Git on DevOps). Some team members in our team are doing iOS development for this project and since they are not familiar with Eclipse, they are wanting to use the CLI instead. Other developers in the same team will continue to use Studio since they are writing Java code for the MFP adapters and want to leverage the capabilities Eclipse provides such as compilation, code auto-completion, etc.
Problem:
After pulling down the MFP project code from Git (fresh pull), if Studio is first used to “Build All Environments” and “Run on MobileFirst Platform”, we can then run the MFP app without any problems. We can then also switch to the CLI for building and deploying artifacts and the CLI commands work just fine.
Now, say that after pulling down the code from Git (fresh pull), instead of using Studio, we start using right away the CLI for building and deploying artifacts. Under such scenario, the CLI throws errors. It seems that the CLI is missing steps that Studio knows how to do. The errors we get when using the CLI right away for building and deploying (mfp bd) after a fresh pull from Git are the following:
$ mfp bd
All apps and adapters were successfully built.
Initializing MobileFirst Console.
BUILD FAILED
/Applications/IBM/MobileFirst-CLI/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml:147: Compile failed; see the compiler error output for details.
Total time: 1 second
Error: Build process failed. Please check the stack above for details.
BUILD FAILED
/Applications/IBM/MobileFirst-CLI/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml:380: Element <project> inside <configureApplicationServer>: File '/Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp/bin/HatchReadyApp.war' does not exist.
Total time: 1 second
Error: Build process failed. Please check the stack above for details.
objc[81801]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
Starting server worklight.
Server worklight started with process ID 81800.
[wladm] Unexpected response from http://192.168.1.126:10080/worklightadmin/management-apis/1.0/runtimes/HatchReadyApp/adapters?locale=en_US:
[wladm] <?xml version="1.0" encoding="UTF-8"?>
[wladm] <deploy-adapter-result ok="false" productVersion="6.3.0.00-20150214-1702">
[wladm] <transaction id="168" type="UPLOAD_ADAPTER" status="FAILURE" timeCreated="2015-04-13T13:53:18.599Z" timeUpdated="2015-04-13T13:53:18.870Z" userName="admin" appServerId="Liberty">
[wladm] <project name="HatchReadyApp"/>
[wladm] <description filename="SBBAdapter.adapter" name="SBBAdapter" alreadyDeployed="false"/>
[wladm] <errors>
[wladm] <error mbeanName="com.worklight.common.server.jmx.api:qualifier=HatchReadyApp,type=ProjectManagement" date="2015-04-13T13:53:18.831Z" phase="PREPARE" code="FAILURE" exception="RuntimeException" details="Runtime synchronization failed. Cannot deploy adapter to runtime"/>
[wladm] </errors>
[wladm] <warnings/>
[wladm] </transaction>
[wladm] </deploy-adapter-result>
Error: The MobileFirst server that you have configured does not appear to be running. Start the server with 'mobilefirst start'.
More details:
If I start the MFP server first before doing a 'mfp bd', it also fails with a similar error:
$ mfp start
Initializing MobileFirst Console.
BUILD FAILED
/Applications/IBM/MobileFirst-CLI/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml:147: Compile failed; see the compiler error output for details.
Total time: 1 second
Error: Build process failed. Please check the stack above for details.
BUILD FAILED
/Applications/IBM/MobileFirst-CLI/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml:380: Element <project> inside <configureApplicationServer>: File '/Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp/bin/HatchReadyApp.war' does not exist.
Total time: 1 second
Error: Build process failed. Please check the stack above for details.
objc[55444]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
Starting server worklight.
Server worklight started with process ID 55443.
MFP info output:
$ mfp info
OS: darwin x64
Release: 14.1.0
System Memory: 89MB free out of 16384MB
Node: v0.10.30
MobileFirst CLI: 6.3.0.00.20150214-1708
Current directory: /Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp
Current project: /Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp
Adapter: getOffers (/Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp/adapters/SBBAdapter/SBBAdapter.xml)
Description: SBBAdapter
Type: http
Procedures: test, getUser, getAccounts, getTransactions, getGoals, getDashboardData, getFeasibility, submitAuthentication, getTradeoffSolution, getOffers
Application: Hatch (/Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp/apps/Hatch/application-descriptor.xml)
Description: Hatch
Type: hybrid application
Features:
Environments: iphone
Skins:
Server location: /Users/olivieri/.ibm/mobilefirst/6.3.0/server
Server binary: /Users/olivieri/.ibm/mobilefirst/6.3.0/server/wlp/bin/server
MobileFirst instance: /Users/olivieri/.ibm/mobilefirst/6.3.0/server/wlp/usr/servers/worklight
objc[85669]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
WebSphere Application Server 8.5.5.3 (1.0.6.cl50320140731-0257) on Java HotSpot(TM) 64-Bit Server VM, version 1.7.0_51-b13 (en_US)
Environment variables:
TERM_PROGRAM: Apple_Terminal
ANDROID_HOME: /Users/olivieri/android-sdks
SHELL: /bin/bash
TERM: xterm-256color
TMPDIR: /var/folders/c9/gf_f0_sd60q1mm9kxwgvlxsr0000gn/T/
Apple_PubSub_Socket_Render: /private/tmp/com.apple.launchd.JKtd63AtGc/Render
TERM_PROGRAM_VERSION: 343.6
TERM_SESSION_ID: D5FA1866-C7B1-4AC0-A045-B8BD0AF18A5D
ANT_HOME: /Users/olivieri/Development/apache-ant-1.9.4
USER: olivieri
SSH_AUTH_SOCK: /private/tmp/com.apple.launchd.ECR6tzx7Xe/Listeners
__CF_USER_TEXT_ENCODING: 0x1F5:0x0:0x0
PATH: /Users/olivieri/Development/apache-ant-1.9.4/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/IBM/MobileFirst-CLI:/Users/olivieri/Development/gradle-1.12/bin:/Users/olivieri/android-sdks/tools:/Users/olivieri/android-sdks/platform-tools
PWD: /Users/olivieri/git/Ready.App.3.Hatch/HatchReadyApp
LANG: en_US.UTF-8
XPC_FLAGS: 0x0
XPC_SERVICE_NAME: 0
SHLVL: 2
HOME: /Users/olivieri
LOGNAME: olivieri
DISPLAY: /private/tmp/com.apple.launchd.8nfQqEAeMS/org.macosforge.xquartz:0
_: /Applications/IBM/MobileFirst-CLI/IBMnode/bin/node
WLP_USER_DIR: /Users/olivieri/.ibm/mobilefirst/6.3.0/server/wlp/usr
Thanks to the IBM folks who helped us resolve this problem. To fix this issue, we had to make two changes to the following file: /Applications/IBM/MobileFirst-CLI/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml
We replaced the following two sections [in this file] as shown below:
1)
<!--
<path id="server-classpath">
<fileset dir="${worklight.jars.dir}" includes="worklight-jee-library.jar" />
<fileset dir="${worklight.server.install.dir}/wlp/dev" includes="**/*.jar" />
</path>
-->
<path id="server-classpath">
<fileset dir="${worklight.jars.dir}" includes="worklight-jee-library.jar" />
<fileset dir="${worklight.server.install.dir}/wlp/dev" includes="**/*.jar" />
<!-- add server/lib folder to classpath -->
<fileset dir="${worklight.app.dir}/../server/lib" includes="**/*.jar" />
</path>
2)
<!--
<target name="build-WAR" description="Build worklight WAR for project">
<echo message="Building worklight WAR for project ${ProjectName}" />
<javac
srcdir="server/java"
destdir="bin/classes"
classpathref="server-classpath"
verbose="true"
includeantruntime="false"
/>
<war-builder
projectfolder="${basedir}"
destinationfolder="bin/war"
warfile="bin/${ProjectName}.war"
classesfolder="bin/classes">
</war-builder>
</target>
-->
<target name="build-WAR" description="Build worklight WAR for project">
<echo message="Building worklight WAR for project ${ProjectName}" />
<!-- first clear out the existing bin/classes contents -->
<delete includeemptydirs="true">
<fileset dir="bin/classes" includes="**/*"/>
</delete>
<javac
srcdir="server/java"
destdir="bin/classes"
classpathref="server-classpath"
verbose="true"
includeantruntime="false"
/>
<if>
<available file="server/java/resources" />
<then>
<!-- now copy the contents of server/java/resources into bin/classes so they get included in the war -->
<copy todir="bin/classes/resources" failonerror="false">
<fileset dir="server/java/resources"/>
</copy>
</then>
</if>
<war-builder
projectfolder="${basedir}"
destinationfolder="bin/war"
warfile="bin/${ProjectName}.war"
classesfolder="bin/classes">
</war-builder>
</target>
After making the above changes, we could then run the 'mfp restart' and 'mfp bd' commands without any errors.

MSBuild publish web project from command line does Package instead of FileSystem

I have a web project that I am publishing from the command line, using a publish profile that does a few additional tasks (excludes some files and folders, grunt, publishing another project in turn).
One two machines (A and B), it works fine from right-click > Publish... in Visual Studio, and choosing the correct publish profile.
Historically, on both machines, it has also worked with the following command line:
msbuild MyProject.csproj /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=myProfile /v:n
However now, machine B is not publishing correctly.
The publish profile is configured with <WebPublishMethod>FileSystem</WebPublishMethod at the top, however from the logs, it is attempting a Package publish type instead, for no apparent reason.
Here is the full publish profile:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>..\Production</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
<ExcludeFoldersFromDeployment>Content;Scripts;Pages</ExcludeFoldersFromDeployment>
<ExcludeFilesFromDeployment>index-dev.html;index.html;debug.html;JSLintNet.json;Gruntfile.js;package.json;packages.config;publishall.bat;publishapi.bat</ExcludeFilesFromDeployment>
<BuildDependsOn>
$(BuildDependsOn);
RunGrunt;
PublishApi;
</BuildDependsOn>
</PropertyGroup>
<Target Name="RunGrunt">
<Message Text="Running grunt production..." />
<Exec Command="grunt production" />
</Target>
<Target Name="PublishApi">
<Message Text="Publishing API..." />
<Exec Command="publishapi" />
</Target>
</Project>
As you'd expect, because it is just doing a Package, no files ever appear in the publishUrl directory. Again, the publish profile works fine from VS2013, using right-click publish.
In the log on machine A I get this excerpt:
**ValidatePublishProfileSettings**:
Validating PublishProfile(myProfile) settings.
But in machine B it doesn't appear.
Later in the log on machine A it contains:
**WebFileSystemPublish**:
Creating directory "..\Production".
Copying obj\Release\Package\PackageTmp\cache.manifest to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\cache.manifest.
Copying obj\Release\Package\PackageTmp\Global.asax to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Global.asax.
Copying obj\Release\Package\PackageTmp\Web.config to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Web.config.
Copying obj\Release\Package\PackageTmp\bin\MyProject.dll to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Blithe.Web.Collect.dll.
but later in the log on machine B, in place of the above, it contains:
**Package**:
Invoking Web Deploy to generate the package with the following settings:
$(LocalIisVersion) is 7
$(DestinationIisVersion) is 7
$(UseIis) is True
$(IisUrl) is <<<some url>>>
$(IncludeIisSettings) is False
$(_DeploymentUseIis) is False
$(DestinationUseIis) is False
The only difference I can think of between the two machines, is that I installed an update on machine B (the problem machine) for 'Windows Azure SDK for .NET (VS2013) - 2.3'. Any ideas how and why this might have broken it?
I tried adding /p:PublishProfileRootFolder="Properties\PublishProfiles" as mentioned here but this didn't work.
Adding:
/p:VisualStudioVersion=12.0
to the command worked.
Machine B had Visual Studio 2008 installed on it as well, whereas Machine A didn't. Setting the version to 12.0, or even 11.0 works. Setting it to 10.0 ignores the publish profile and just does a package install.
Surprisingly it seems to default to 10.0.
This issue did not emerge until the update to Azure SDK 2.3, which DID have some changes to Web Publish, so that may well have led to this issue.

NuGet Package Restore does not fetch Build Target Assemblies (Tools)

I added Fody ProperyChanged to two projects in my solution. Package Restore is enabled on the solution. However, the TFS Build Service fails building with the following error:
WindowsUI.csproj (443): The imported project
"SolutionDir\Tools\Fody\Fody.targets" was not found. Confirm that the
path in the declaration is correct, and that the file exists
on disk.
The folder is indeed not there. I could check it into source control, obviously. However, should it not be populated by the NuGet Package Restore? Or am I misunderstanding what NuGet Package Restore does?
I ran into a similar problem trying to get a solution to build on Visual Studio Online.
Problem is that packages are restored before a project build, but before that the project
files and target inclusions from packages (still to be restored) have already been interpreted.
Use the before build hook as described here:
http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
In your before.solutionname.sln.targets file put something like this to force all packages to be restored before even the first project is built:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BeforeBuild" BeforeTargets="Build">
<Message Text="Restoring all nuget packages before build" Importance="high">
</Message>
<Exec Command=".\.nuget\NuGet.exe restore YourSolution.sln" />
</Target>
</Project>
If you have external package sources configure them in your nuget.config file which should
also be in the .nuget folder. For example:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="YourSource" value="http://yoursource.somewhere.net/nuget" />
</packageSources>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<!-- Automatically check for missing packages during build in Visual Studio -->
<add key="automatic" value="True" />
</packageRestore>
</configuration>
As of version 1.13.0.0 (released March 23, 2013) Fody is a 100% nuget deployed tool and as such it will work with package restore.
https://nuget.org/packages/Fody/
This will appear when you install the Fody Nuget
https://github.com/Fody/Fody/blob/master/NuGet/readme.txt
UPDATE: This answer now only applies to versions prior to 1.13.0.0.
The files in SolutionDir\Tools\Fody cannot be deployed through nuget and needs to be checked into source control
You are running into the same issue that I did when I tried to ship a build update in NuGet package. The issue is that NuGet package restore is invoked during the build process. Because of this if NuGet package restore restores a .targets file that is imported, it is restored too late. By the time the file is written to disk the <Import element has already been evaluated and skipped due to the file not being on disk.
The best thing that I have found is to build another project to invoke the package restore for you. In order to smooth this out for my own SlowCheetah NuGet package when the NuGet package is installed I create a packageRestore.proj file in the same director as the .csproj/.vbproj. Then users can build this project file and then the .sln/.csproj/.vbproj. By doing this the NuGet packages are restored and then the build process is kicked off.
If you are interested in using my packageRestore.proj I can re-factor that part of SlowCheetah NuGet package into its own and your NuGet package can depend on that one. Let me know if you are interested in that.

Where is sun-appserv-ant.jar for Glassfish v3

Where is sun-appserv-ant.jar in Glassfish v3
I have created a small sample EJB project and I want to use ant to deploy the application to Glassfish v3.
Ive spent a lot of time on google trying to achieve this and all ant samples seem to refer to a jar file called "sun-appserv-ant.jar" which is supposed to be located in the modules directory of the application server install, however, I cannot find it anywhere, nor can I seem to find the reason why, or if there is even an ant based alternative.
Thanks
The sun-appserv-ant.xml file was not brought forward with v3.
You are not completely stuck though.
You can read about the Ant exec task, which you can use to trigger asadmin commands.
If you are very adventurous, you may want to investigate the bp-project framework that is used by the sample projects that ship with the Java EE 6 SDK.
You can get a peek at the bp-project framework by looking at the code in the glassfish-samples repository.
You should add the glassfish-ant-tasks module through the GlassFish Update Tool
After much agony I found an example of how to use the V3.x ant tools here
The downside, for non-French-speakers, is that it's in French. The upside is that the Java parts are still in Java.
From what I can tell, the Ant tasks now differ significantly from what is documented by Sun (Oracle):
You must use the Glassfish server update tool to get the glassfish-ant-tasks module.
This will cause the file *glassfish_dir*/lib/ant/ant-tasks.jar to be downloaded. That must be included on your classpath
Define an as-ant-init target in your build.xml
<target name="as-ant-init">
<taskdef name="sun-appserv-deploy"
classname="org.glassfish.ant.tasks.DeployTask"
classpath="${build-lib}/ant-tasks.jar" />
<taskdef name="sun-appserv-undeploy"
classname="org.glassfish.ant.tasks.UndeployTask"
classpath="${build-lib}/ant-tasks.jar" />
<taskdef name="sun-appserv-component"
classname="org.glassfish.ant.tasks.ComponentTask"
classpath="${build-lib}/ant-tasks.jar" />
<taskdef name="sun-appserv-admin"
classname="org.glassfish.ant.tasks.AdminTask"
classpath="${build-lib}/ant-tasks.jar" />
<taskdef name="sun-appserv-redeploy"
classname="org.glassfish.ant.tasks.RedeployTask"
classpath="${build-lib}/ant-tasks.jar" />
<taskdef name="sun-appserv-start-server"
classname="org.glassfish.ant.tasks.StartServerTask"
classpath="${build-lib}/ant-tasks.jar" />
<taskdef name="sun-appserv-stop-server"
classname="org.glassfish.ant.tasks.StopServerTask"
classpath="${build-lib}/ant-tasks.jar" />
</target>
Write the deployment target. The rules are similar to what's in the documentation, EXCEPT
A. Remove references to the <server> element that was used in older versions.
B. All of the attributes that would have been attached to <server> in the older version of the API are now attached directly to the containing element, such as <sun-appserv-deploy>, like so:
<target name="deploy">
<sun-appserv-deploy
user="${glassfish.admin-user}"
passwordfile="${glassfish.passwordfile}}"
host="${glassfish.host}"
port="${glassfish.admin-port}"
installDir="${asinstalldir}"
upload="true" >
<component
file="${dist.warfile}"
name="My application"
contextroot="${glassfish.context-root}" />
</sun-appserv-deploy>
</target>