I created my own framework, which itself depends on the RestKit framework.
I created an App which uses my framework, and I added to the app the RestKit framework as described by their tutorial.
I use the latest version 0.20.2 and if I build it in Xcode (either simulator or to the device) all works fine.
As soon as I want to create an archive it can't find the <RestKit/RestKit.h> header anymore.
How do I need to adapt the Header Search Paths so it will find the RestKit even when building for an archive? (at the moment my framework only contains "$(BUILT_PRODUCTS_DIR)/../../Headers")
I already tried This solutions but unfortunately without any success.
For your release configuration, specify a recursive search path of:
"$(BUILD_ROOT)/../"
Related
I've been working on a VS Code extension that uses Roslyn's workspace API to load a project, at the moment the extension supports .NET Core's old project.json format via the ProjectJsonWorkspace type in the Microsoft.DotNet.ProjectModel.Workspaces package.
With the new tooling changes being released soon I'm keen to support the new .csproj build format but can't appear to find a .NET Standard compliant workspace that supports it.
My understanding is that as it's using MSBuild, I will need to use the MSBuild (Microsoft.CodeAnalysis.MSBuild) package, however it does not support .NET Standard at this moment in time.
What is the best solution if one exists, or will I have to look at creating my own workspace implementation?
Having spoken with various people it appears that there is no .NET Standard compatible MS Build workspace, this can be seen by this answer below to the following GitHub issue:
We haven't done the work to make MSBuildWorkspace work properly with the new MSBuild cross-platform. In the meantime, you might look at what omnisharp does to populate it's workspace.
So it seems that at the time of writing if you want to target the MSBuild workspace in a .NET Standard compliant project then you'll need to build your own custom workspace using Roslyn's workspace API, this is exactly how OmniSharp do it.
Update (16/10/2017):
Whilst MSBuildWorkspace does still not support .NET Standard, there is a library called Buildalyzer that works cross-platform and will generate an AdhocWorkspace for you, allowing you to achieve the same goal.
using Buildalyzer.Workspaces;
// ...
AnalyzerManager manager = new AnalyzerManager();
ProjectAnalyzer analyzer =
manager.GetProject(#"C:\MyCode\MyProject.csproj");
AdhocWorkspace workspace = analyzer.GetWorkspace();
The same library will also allow you to reference a solution file too.
Following the guidelines here: http://docs.ionic.io/docs/push-from-scratch I am having trouble with step 2 - installing ionic add ionic-platform-web-client.
My index file within my app adds <script src="lib/ionic-platform-web-client/dist/ionic.io.bundle.min.js"></script> as it should, however the file doesn't exist at this location, even after running 'ionic lib update'.
(For ease of explanation in this section I am using the non minified version of the bundle: ionic.io.bundle.js (the results are the same with both full and minified versions of the files)).
Manually adding ionic.io.bundle.js from https://github.com/driftyco/ionic-platform-web-client/tree/master/dist will give me this error:
"Uncaught TypeError: Cannot call method 'get' of undefined
ionic.io.bundle.js (3429,0)"
from this code:
key: "get",
value: function get(name) {
return this._settings.get(name);
}
I found a 'hacky' way to get the dev pushes working by simply returning this instead of the full return this._settings.get(name) statement, although this only really suits the purpose of debugging and additionally does not allow removal of developer mode by settings 'ionic config set dev_push false' or manually setting "dev_push":false in .io-config.json.
I am unsure as to whether manually adding ionic.io.bundle.js is simply adding to my problems or whether this is the right approach to take and that the errors produced are the real problem?
I am running:
ionic 1.1.0
ionic CLI 1.7.7,
cordova 5.3.3,
bower 1.6.2,
npm 2.11.3,
visual studio 2015 community with cordova/ionic setup,
I've also updated my android platform - for which I am currently building to (deploying to nexus 7).
TheCannot call method 'get' of undefined in ionic.io.bundle.js happens because of missing settings in the bundle.
This could be fixed by running:
ionic config build
Although I still haven't been able to install the ionic web platform via 'ionic add ionic-platform-web-client' in the cli I have managed to get the ionic push notifications working.
Firstly I made sure in my app directory within the cli to use 'ionic lib update'. As the setup of my project was different (thanks to visual studio). You will likely already have these files using a custom setup, but I found it's good to have the directories in place.
Secondly I manually downloaded the web client https://github.com/driftyco/ionic-platform-web-client4 not just the ionic.io.bundle.min.js which seemed to fix my "Uncaught TypeError: Cannot call method 'get' of undefined" problem mentioned previously, after I moved the entirety of this in my lib directory. (Make sure the name of the downloaded folder matches: "ionic-platform-web-client" exactly, and doesn't contain any words like master).
Thirdly, as I couldn't add version 1.3.0 of the push plugin (which continually gave me the beloved 'uh oh' error) I used 1.2.3 instead. I installed this via: 'cordova plugin add https://github.com/phonegap/phonegap-plugin-push.git#1.2.31'. Although I have just noticed 1.4.0 is available which may also work?
This should hopefully fix any issues you have, even if it's not a perfect solution. As a side note: I know it is mentioned somewhere on one of the ionic pages that you need to have a traditional project setup and then move the relevant files but it would be nice to have some description of how to go about this - as you may not know what the relevant files are. For anyone who comes here scratching their heads, If you're using visual studio to create your ionic projects from scratch or any other custom setup, you will likely run into the same issues, as the relevant directories created using 'ionic start myApp' will likely have been omitted.
Our company's svn cannot allow single file larger than 40mb, realm framework needs 140mb+，so how can I build realm-cocoa with source code on github?
You could instead use the dynamic framework, which is a lot smaller (28,5 MB), through being already linked, but you won't be able to support iOS 7 in that way.
Alternatively I would recommend using a dependency manager like CocoaPods, which helps you with the setup and integration. But as a Core Member of this project, I'm obviously biased in that regard.
If that shouldn't be available for you, then you could theoretically use SVN externals to checkout the realm-cocoa repo (GitHub supports SVN transports), add the Realm.xcodeproj to your Xcode project, set the iOS framework target as dependency target of your app target and link to Realm.framework. But please not that this is not an officially supported way of integration.
When I create an app using composer, or install another app created using composer, there is a vendor/symfony folder included.
For example, I installed Laravel using composer. The folder vendor/symfony is present. I am not specifically referencing this in my Laravel app at all.
What is this folder, and it needed? Does the app use it, or composer use it? So if I am using an app created using Composer and dont use composer myself, can it safely be deleted and the app still run? Or could the app be using it?
Thanks
Answer is quite simple: Laravel uses Symfony components.
Check this article: http://www.sitepoint.com/build-php-framework-symfony-components/
Improved Routing Engine
Laravel 4.1 features a totally re-written routing layer. The API is
the same; however, registering routes is a full 100% faster compared
to 4.0. The entire engine has been greatly simplified, and the
dependency on Symfony Routing has been minimized to the compiling of
route expressions.
http://laravel.com/docs/master/releases
The "vendor" folder is a standard in every application / framework that uses composer to manage dependencies. In the "vendor" folder you will find all dependencies (read: libraries) that your applicatication requires.
But you will also find all libraries that your libraries require. In order to minimize code duplication, and thanks to the composer system, most open source projects now reuse parts from other open source projects.
BTW, this is great.
Symfony components are excellent and well documented, so they are currently used by many other frameworks and applications.
Inside the "vendor" you may find other libraries that you did not specifically require yourself, but as long as your correctly use composer, that's not something you should worry about.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.