Is there a way to set the 'iOS Application Target Bundle Identifier' per 'Build Configuration' in Xamarin?
In XCode you can do that, which means that the same base code can be compiled for different enterprise customers (our case).
Xamarin Studio allows creating 'Build Configurations', and different provisioning profiles can be used in each one, however, it doesn't seem to have a way to set the Bundle Id.
Please advise. Thanks.
Not directly. However you can create pre (or post) build steps scripts (see Custom Commands in your project's options), which knows among other things the configuration being built, i.e. ${ProjectConfig}.
From the script you can use a tool, like PlistBuddy, to modify the Info.plist file values.
You can create and enviroment variable containing the bundle id and add it to the plist file as a pre-build step, this is what I did in my project
if [ -n "$MY_BUNDLE_ID" ]; then
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $MY_BUNDLE_ID" ${PROJECT_DIR}/shell/shell-Info.plist
fi
For now, there is still no direct way to do it. Create the bundle identifier in XCode and utilize that in your Xamarin project.
Related
i am using hybris version 2005
I installed addon with this command
ant addoninstall -Daddonnames="notificationaddon" -DaddonStorefront.yacceleratorstorefront="myStorefront"
How can I run adon without using this command on all devices? Where should I add what settings
Afaik there is no need to install an addon on all "devices", the addoninstall call changes two files in the destination extension e.g. the storefront extension:
myStorefront/.classpath
myStorefront/extensioninfo.xml
These files are usually under source control, so if you commit them, every time the project is built there is an ant macro that copies the addon into the extension directory.
Additionally, the addon should be added to the localextensions.xml, usually there is an template for the local dev env and the production, both should be updated.
I understand by devices, you mean the servers? If this is right, then you do not have to run this on servers. Instead, let the CI script take care of this. Based on the deployment strategy, your script would automatically run this command and the addons get installed on the storefront.
Every Addon does different work and requires a different way of inclusion.
The add on has a file project.properties.template that contains the properties that become active once you install the addon.
The addon has build.xml that is used to build that along with the storefront extension, whenever called back.
The source code including the java and XML that gets compiled along with the storefront. An AddOn can override any resource in the storefront extension.
For further information, please visit the Addon Concept illustrated in SAP help portal.
what is bundle installation script in netsuite and its purpose. I tried it to
Suite Answers but could not figure out. Any help regarding to topic will be valuable.
thanks.
There is only two cases where I have seen it used.
To use it as part of license management. A bundle installation script can check with a third party system to check if the account where the bundle being installed has a valid license.
To check if the features that your bundle needs is activated or available in the account it is being installed on.
The bundle installation script can also be used for data migration, when the bundle is updated. ie Suppose in the newer version of the bundle, you are adding one new custom field. For the existing custom records in the customer account, if you want to default that custom field to a particular value, after the bundle update, then you can do the same via bundle installation script (Using the afterInstall hook)
Using Visual Studio 2012, Azure SDK 2.1, I am trying to figure out the best way to create the csx folder for running in the azure emulator. My understanding is that the csx folder is not created until I package the Azure project. I can create a package manually from Visual Studio, but this is not an option for an automated build. The other option is to create the package using the msbuild command line. This seems a bit heavy handed as it will actually do a build which is more time consuming than just repackaging.
So, I thought that cspack might be a more lightweight option. However, when I call cspack with the following command line:
cspack.exe ServiceDefinition.csdef /copyOnly
I get the error: Need to specify the physical directory for the virtual path 'Web/' of role MyProjWeb.
But, I don't do anything like that when using msbuild. I have read a bunch of things about specifying the physical directory and some of the confusion that it can cause. So, I would prefer not to use it unless absolutely necessary, especially since I don't need to specify this when building from msbuild.
So, my main question is what is msbuild doing that cspack is not doing and how do I do the same with cspack?
My other question is, what is the easiest way to generate the csx folder for testing in the azure emulator?
Edit - Resolution
I thought that I would put down how I resolved this here in case it helps someone else. The big answer to my question (thanks to Chandermani and some other reading) is that CSPack with /copyOnly is basically a fancy xcopy to a folder structure according to some rules. If not using /copyOnly it then also does a fancy zip to create a package. Not complaining, it is fine that it is simple, but it is good to know this at the outset. You can use it for packaging anything for azure it is not tied to what can be built in Visual Studio, e.g. a PHP site. Using msbuild has the added benefit of only copying that files that are part of your web site deployment.
So, what I found when I got CSPack working and pointed at the mvc project folder is that it copied everything including source files. Which is not what I wanted. The solution that I could find is to first package the web site then point CSPack at the packaged files. If you do down this path then this link is very valuable as it describes it step by step.
So, it was either having an msbuild post-step in the Web project to package the files and then a post-step in my Azure project to cspack it or to have an msbuild post-step in my azure project to create the package (do cspack with the benefit of only including my web deployment files). Well, it seemed simpler and less error prone to just to have the one post step and let msbuild do the heavy lifting. So, the post step in my azure project is something like:
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devfabric:shutdown > NUL
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devstore:shutdown > NUL
if $(ConfigurationName) == Debug set CONSTANTSPARAMETER=DEBUG
if $(ConfigurationName) == Release set CONSTANTSPARAMETER=
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe $(ProjectDir)$(ProjectFileName) /t:clean;publish /p:Configuration=$(ConfigurationName) /p:TargetProfile=cloud /p:OutputPath=bin\Cloud$(ConfigurationName) /p:VisualStudioVersion=11.0 /p:overwritereadonlyfiles=true /p:DefineConstants="%CONSTANTSPARAMETER%" /verbosity:minimal /p:PostBuildEvent=
The first two lines shut down the compute and storage emulator.
The next two lines set the preprocessor constants. I found that #if DEBUG was no longer taking effect when built using the msbuild line. I think that this is safety protection that DEBUG is stripped when creating a package. I only ever use the package that is created by an automated build system, so it is safe for me to keep the DEBUG constant.
The actual msbuild line has a number of switches. I'll describe the unusual ones:
/p:PostBuildEvent=
If we don't set the postBuildEvent to empty then the same post step will keep getting called forever. And ever...
/p:VisualStudioVersion=11.0
Those clever guys at Microsoft made it possible to open projects with both Visual Studio 2010 and 2012. Which is great, but can bring great sadness when you run msbuild from the command line and end up with nasty MSB4019 error messages because it is looking in the wrong Visual Studio folder for the Azure tools.
Also, note that that I use the cloud profile. Since I am only after the csx files it doesn't seem to make a difference whether I use local or cloud at this point. When I run in azure I specify ServiceConfiguration.Local.cscfg.
Edit: In the end I took this out of the post step and put in my automated build. My original intention was that running the tests from my dev machine would be the same as my automated build, but the post step took too long and the views were sourced from the obj folder rather than the proj folder when running under the debugger which meant I had to copy across when making changes on the fly.
Unanswered questions
It would still be good to understand how msbuild does things to reduce knowledge friction when dabbling in this area. Does it create a package for the website and pass it to CSPack? Or does it parse the project files and then pass some crazy arguments to CSPack? Also when you run an azure project in the debugger, it runs in the emulator with only the binaries in the csx folder (not the images, etc). How does it do that? It would be great to see some description with pictures of the Azure build pipeline with that showed the lifecycle all the way to deployment. That might also explain why there are two copies of the binaries. Also, this would have been a whole lot easier if Visual studio had a project flag like packageOnBuild for the Azure project with options to do a copyOnly or to create a package. I see no point in uneaten cake. Edit: There is a DeployOnBuild setting that can be added to csproj.
Finally, as I mentioned the whole purpose of this is to get a csx folder that I can point the emulator at so that I can run my unit tests on my dev machine. I do the formal packaging on a build machine so don't really need it in Visual Studio. So, really I don't want to package anything and was hoping that there was an easier way of achieving all this.
Since msbuild uses the the azure project file to perform the build, it can derive a lot of information form the project file.
For cspack, the assumption is the role code has been compiled and is available for packaging. Since cspack does not depend upon project file, it needs a explicit information for the code path of the the web\workerrole project. The csdef file does not contain any such information. I suggest if you want to use cspack. Look at its documentation and try to create a package for emulator deployment from command line (CopyOnly option). Once you find the correct syntax you can embed it in you build script.
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
I created my iPhone app with MonoTouch and deployed it to the AppStore. Now I want to add a free lite version of the same app. What is the best way to do this with MonoTouch/MonoDevelop?
So far I created a new Provisioning Profile for the lite version. I can change the build options to use the full or the lite profile. But what else do I have to change and how? I think at least the app name should be changed, but how???
Thanks,
Christian
The way I do these things is to create a new project, then add the existing c# files from the first project as a link. You will see this option on the "add existing file" dialog. Keep in mind all your Icon/Splash screen files will have to be copied though, MonoDevelop doesn't handle these right if they are linked.
Just a side note, you can get by with less provisioning profiles. Create one as com.yourcompany.*, then name your apps com.yourcompany.yourapp1, yourapp2, etc.
So I have a profile for Development, AdHoc, and AppStore, but I have several apps deployed.
Rather than link files, I prefer to make three projects: A library project which will have all the UILogic called X.Touch.Core and two more which will have a reference of the Core. X.Touch.Lite and X.Touch.Premium. This way you don't need to have linked files, it can be painful. You can put a file called settings.xml and perform some feature toggling there.