The problem is that when I create a framework for iOS, that uses a different framework, I have to also include the second framework in my application.
What I want to try is to compile the second framework into the new one that uses it. so it's all one package. Is this even possible?
If so, how?
It's possible but strongly recommended against. If two frameworks both include another framework in this manner, you wouldn't be able to use both in the same project as the symbols would conflict. https://stackoverflow.com/a/14197817/72176
If the second framework is licensed in a way that it can't be given away separately with your framework, I'd be very surprised if you were permitted to distribute it as part of your framework either.
Related
I'm trying to create a simple Blazor client server app using EF, similar to this article.
So I've got a client, server, and common libraries, and this worked fine. But then I added the EF component to the common library, so that I could use real data from my database, instead of toy data from the demo.
I tried making them all Core 3.0, but this doesn't work because Blazor seems to require .NET Standard 2.0. Without that, I get all kinds of errors.
But then the common library can't use EF, because (if I'm reading this right) EF6 isn't supported on Standard 2.0. If I try, I again get tons of errors.
So I'm not sure, but I can't find any scenario that would allow me to share EF objects between client and server--which is a major rationale for Blazor.
Is there some other way to accomplish this?
The shared library should not use or reference EF.
Add EF to the Server project only and make the data available through an API controller.
You should make the common project netstandard and use EF core (not EF 6)
I have existing project written in Zend Framework 1, it is long term project, constantly developed and without possibility of migrating to ZF2. It would be really neat to use Symfony2 Web Profiler bundle in it.
Currently, in development, I am using zfdebug (https://packagist.org/packages/spekkionu/zfdebug) which is great, but bundle from Symfony2 has so much more to offer...
I managed to incorporate Composer into my application (in Bootstrap), so loading something with it should be no problem. Also I found package on Packgaist (https://packagist.org/packages/symfony/web-profiler-bundle) but to be honest - I don't know if it is even usable without Symfony2.
Thanks for any tips.
No, this is not possible. If you take a look at the requirements on packagist you see it requires symfony/http-kernel, symfony/routing and symfony/twig-bridge to work. That's because the way the WebProfilerBundle works:
It registers himself at the most common events, the events happening in the HttpKernel and Routing component. If he cannot register to these events, he will not be able to give you timer information.
Moreover, it uses another event to inject imself in your page, meaning that if you don't have that event, you will never see the bar.
And the bundle is using Symfony conventions and techniques, meaning that it cannot run on ZF conventions and techniques. This is why it is called a Bundle instead of a Component, components are stand alone, bundles aren't.
I am developing a (free, open-source) Entity Framework tool, it is basicaly an ADO.NET provider, but it uses some higher abstractions too (e.g. ObjectContext, EntityConnection). I want it to support almost all the legacy version of EF (EF4=<). Until EF5 came out it was quite easy, because I had been able to develop it by targeting only .NET40.
EF5 made the things more complicated, because some of the new features requires the .NET45 framework. On the other hand, EF5 supports .NET40 too. An on the top of that, EF is now developed independently from the .NET framework.
For now, It is obvious that targeting both .NET40 and .NET45 is inevitable. But currently I have no idea what is the best way to setup a multi-target environment that can comply with the independently developed EF. I also haven't found any good document about this problem.
Should I use multiple solution files? Multiple project files? Multiple solution configurations? Reference all version of EF somehow? Create an universal build script? If yes, how? How to run my unit test against different configurations? How to indicate that a test can/should fail in a specific configuration? What about the changed namespaces (e.g. ObjectContext)? Should I use #if directive to solve this conflict? What if a new EF release requires to implement a feature that will break the compatibilty with previous versions? I am really uncertain at this point.
Take a look at the EF6 code base at http://entityframework.codeplex.com/. We build EF6 for .NET 4 and .NET 4.5 in essentially the way you are suggesting--using multiple build configurations.
Some other points to consider:
If you don't make use of any .NET 4.5 APIs or behaviors, then you may be able to just target the .NET 4 version. If you are using anything from EntityFramework.dll, then this may require a binding redirect to use the 5.0 version, but in a lot of cases if you ship as a NuGet package then NuGet will handle this for you.
If you plan to support EF6, then keep in mind that the core types have been moved out of the .NET Framework. This means, for example, that the EF5 ObjectContext is a different type from the EF6 ObjectContext. You will likely have to compile your provider code twice to create EF6 and EF5 versions in order to handle this. More information can be found here: http://entityframework.codeplex.com/wikipage?title=Rebuilding%20EF%20providers%20for%20EF6
I created framework, that uses ASIHTTPRequest.
Than i added this framework into my project that already uses ASIHTTPRequest. And i got
ld: duplicate symbol ...
What is the correct way in this situation?
objective C has no namespace support it will guess which class to use with undetermined results.
On the other hand, you should not be exposing internal headers from your framework, not sure if that is the cause.
Either way, you have to pick one option or rename all your private ASIHttpRequest classes to avoid the conflict.
If you know the dependency is available then just use it from a dependent framework. This is just a build problem not a deal killer in most cases.
I have a model library (namespace Test.App.Model.EF) with the Entity Framework implementation in it. This has all of the entities provided in the EF designer for me which I want to use. Within this Model.EF implementation, I have several repository classes. I want to create interfaces for these classes and place them in a seperate interface library (Test.App.Model.Interface). So I do so, obviously the implementation library needs a reference the interfaces. BUT, I notice that the interfaces need to know about the objects in the EF designer (since I want to reuse them). I can't create a reference from the interface library to the ef implementation because then I'll have a circular reference.
So, as I write this, I'm coming to the conclusion that I'll probably need a Test.App.Entities.EF that has the Entity Framework "created" entities. That way my interfaces lib could reference without having to know about the Model.EF.
Does that sound like the way to go?
Ok, so after much wrestling with this, I found the buzz term that describes the situation. What I'm looking for here is called "Persistence Ignorance". This is what would make what I described in my thread happen. Well the Entity Framework that we use (not 4.0) does not support this yet (unless you go homegrown like done here).
With having that said, EF 4.0 will have this feature but from what I understand, it's coupled with .NET 4.0 (why it's called EF 4.0 in the first place) and that's not going on our production servers anytime soon. Since we've decided to go with this technology, our repository abstraction to interfaces will be placed on hold until upgrading to 4.0 is a viable option.
Let this be a caveat for those seeking the same information. Please also let me know if this sounds incorrect (because I would love to make this happen sooner then later but I don't want my team jumping through hoops when a later implementation will remedy the issue). Thanks all!