An answer to a recent question on extending SubSonic pointed to a googlecode directory listing the relevant ActiveRecord templates. I was very surprised to see that most of the CS_ ones are a lot newer than the VB_ equivalents. Does this mean that SS2.2 has not been fully updated for VB?
See this thread
For the reasons why vb.net isn't fully "baked" for 2.2
I committed a patch to the templates and made sure it was included in the VB versions. There weren't many template changes for 2.2, so it should still be fine. Is there something not working for you?
I was kind of surprised that the date stamps had changed on most of the CS_ ones, and not the VB_ ones.
In my case, I'm not having much luck with Winforms data binding, although I not a recent item on the GoogleCode buglist which may be applicable. I think that one is post-2.2?
Related
According to swift.org/migration-guide, dispatch and related functions have a great new swift interface (e.g. dispatch_async -> DispatchQueue.async). Also other foundation types have been added like Data and Date value types instead of NSData and NSDate.
However, on the open source version of swift3 (developer preview 1) on linux, ubuntu15.10 the compiler rejects all of these changes. In fact, looking at the open source version of swift and swift-corelibs on github, I don't actually see any of these changes. Since it will compile on XCode developer preview, this has lead me to believe either: I am doing something wrong on Linux or these changes have been made in the Apple branch and not the open source branch. Can anyone verify this and if the latter is the case, and if so, how do we know what changes will be in the Apple branch vs the open source branch?
As of Swift 3.0 release version GCD is available on Linux with simple import Dispatch, which is slightly confusing as it's not needed on iOS/macOS, where Dispatch module is imported by default.
Thanks to Brad Larson for finding the Foundation and Dispatch overlays in the source. According to swift.org:
SDK Overlays: Specific to Apple platforms, the SDK overlays
(implemented in stdlib/public/SDK) provide Swift-specific additions
and modifications to existing Objective-C frameworks to improve their
mapping into Swift. In particular, the Foundation overlay provides
additional support for interoperability with Objective-C code.
tl;dr anything in these folders are Apple platforms only. Still not sure why they restricted the Dispatch overlays to Apple Platforms since libdispatch is also open source and targeting linux, but this answers my initial question.
Edit: was able to confirm via swift mailing lists that the dispatch overlays do have some reliance on objective-c runtime. There is work to get them implemented for non-Darwin platforms but no guarantees on timing.
Check out the Swift 3 Evolution Github page. They list all the proposed changes to the language, and separate them by those that have been implemented and those that have not. Proposal SE-0088: Modernize libdispatch for Swift 3 naming is on the "yet to be implemented list" as are many other changes.
As far as Data and Date are concerned, I cannot say, since I believe that is part of the upcoming Core Libraries, and I have not yet been able to look at those in great detail yet. Perhaps you might check the Swift Core-Libs Github page as well, though the status page references work done on NSData and NSDate, no mention of the newer data types.
I am trying to parse some GHC Core to extract name information and other bits needed.
I am currently using the GHC API given that I haven't found other useful packages help with it.
I've looked through some packages like ghc-core, ghc-core-html and extcore but they seem slightly outdated and I haven't managed to use extcore with ghc-7.10.3.
I have also tried to look for up to date documentation on Core without luck. The best post I've come across is this one, but the discussion is slightly outdated (e.g. compiling the example from these slides, gives a different core dump using the latest ghc.
The question
Having said all this, do you guys know of any recent package that can help in parsing Core? Is there any new documentation regarding CORE manipulation?
Thanks!
The external core feature was removed because it was buggy and a hassle to maintain and if people were using it they didn't speak up. So there is no longer any textual representation of Core intended for machine consumption. Only the internal (AST) representation is available. Of course, I'm sure you'd be welcome to revive the external representation if you want to maintain it.
Do we need Automapper and Automapper.Net4 dlls together to use the Automaper functionality in our code.
I mean can't we just have the one dll of them both. Using Automapper for the first time.
Need help.
Thanks in advance
All you need to do is do "Install-Package AutoMapper" and you're set. Because AutoMapper supports all major .NET platforms, things that are specific to your platform are in a platform-specific assembly. This is a very common approach for building cross-platform libraries.
In short, you shouldn't care, because NuGet takes care of everything for you. It's completely transparent to you as a user. You don't have to do anything extra to take advantage of the platform-specific features.
Why not ask Jimmy? AutoMapper using Portable Class Libraries.
From looking at the NuGet package, it would appear Automapper.dll is the core (it's common to all platform libraries), while Automapper.Net4.dll is the platform specific - both are necessary.
This is actually the correct answer:
Effectively the .Net4.dll assembly is combined into the one AutoMapper.dll. So you should delete that file. (Jimmy Bogard)
We spent the whole afternoon with a team debugging what is wrong (I got one customer bug report) and could not reproduce. Then finally we found out that the problem is with Automapper.Net4.dll. After deleting it, bug went away (before we already located in the code that the problem is with automapper).
Both are combined into just one nuget Package: Automapper
why we should not use any classes from portal-impl.jar inside your portlet?
In my case, how can I read PropsValues without adding portal-impl to maven dependencies.
I'm using Liferay 6.2
Thanks
#Origineil - in a comment to your question - gave you the alternative of what to do instead of using portal-impl.jar (e.g. use GetterUtil.getBoolean(PropsUtil.get(PropsKeys.SESSION_TIMEOUT_AUTO_EXTEND)); instead of PropsValues.SESSION_TIMEOUT_AUTO_EXTEND.
Why shouldn't you add portal-impl.jar to your project? Well, there are many reasons. First of all: It doesn't work. If you add portal-impl.jar to your plugin, there are quite a lot of spring components in there that would re-initialize - and they'd assume they're in the portal context. They'll be missing other code they're dependent on and you'd basically pull in a lot of Liferay's implementation and dependency code, making your plugin ridiculously big. And the initialization can't be done twice, so it won't even work anyways.
Plus, in portal-impl.jar you'll only find Liferay's implementation details - none of this code is ever promised to be stable. Not only will nobody care if you're depending on it, it'll most likely break your assumptions even on minor upgrades. Of course some components in there are more stable then others, but the basic assumption is a good one.
Liferay's API (that you're encouraged to use) lives in portal-service.jar. This is automatically available to all plugins and it contains the implementation mentioned above. Don't depend on someone's (Liferay's) internal implementation. Rather depend on the published API. If this means that you'll have to implement something again - so be it. It might be slightly less elegant, but a lot more future proof. And if you compare the size of portal-impl.jar to the amount of code that you'd duplicate in the case of PropsValues, you'll see that this single expansion is actually a nobrainer. Don't pull in 30M of code just because you'd rather type 30 characters than 60.
I have a complex sharepoint deploy with multiple EventReceivers and Workflows.
I also have schema changes to existing lists, adding new columns of metadata and changing existing columns.
Should I package a single feature, eventreceiver or workflow, to a single solution, or should I put multiple features inside the single solution since they all work together?
One major reason I am asking is for future code upgrades. If the features are seperated, then an upgrade in one portion of code would not require a re-deploy of all the features in the solution. Is this something I should worry about or does the "stsadmin -o upgradesolution" take care of any issues with the upgrade of a solution with many features?
Let me know if this makes sense to any SharePoint gurus out there.
Thank you,
Keith
Update:
Looking at the website drax referenced, I found this reference site: http://msdn.microsoft.com/en-us/library/aa543659.aspx
This statement seems to put a large handicap on upgrading features in solutions:
Solution upgrade can only be used to
replace files. You can add new files
in a solution upgrade and remove old
versions of the files, but you cannot
install Features or use Feature event
handlers to run code for Feature
installation and activation. The
following operations are not supported
in solution upgrade.
Removing old Features in a new
version of a solution.
Adding new Features in a solution
upgrade.
Updating or changing the receiver
assembly for existing Features in a
new version of a solution.
Adding or changing Feature elements
(Element.xml files) in a new version
of a solution.
Adding or changing Feature
properties in a new version of a
solution.
Changing the ID or scope of old
Features in a new version of a
solution.
Removing Feature elements
(Element.xml files) in a new version
of a solution.
Removing Feature properties in a new
version of a solution.
So... What can you do with a solution upgrade?
I would advise against splitting everything into multiple solutions. Maintaing that can quickly become nightmare. Try to structure your project, which should is used to create WSP, in same manner as 12 folder of sharepoint. Then you can use WSP builder, last stable version brings a lot of useful stuff.
Also i've not noticed any problems with redeploying solutions. According to this article and to my experience deployment of WSP takes care of synchronization between versions. So if you will add some new features they will appear and if you remove/change features they will be modified accordingly.
EDITED:
So I did some quick research on MOSS Updating topic. According to MS there are two ways of updating solutions:
In-place update
Incremental update
Basically, in-place update is standard way of updating. Meaning you are relying on build-in functionality as described in this (same document as posted before) document. Problem with this solution is that it lacks quite a lot of functionality (versioning, changing of ID's of features,...).
Incremental update (this is how MS calls it probably) don't rely on build-in solutions. That means it is up to everybody to implement it by themselves :(. What is even better I was not really able to find any guidelines for this approach. I suppose that approach you would like to take is example of incremental update (splitting project into many independent solutions).
Also note that Incremental update is not officially supported by MS.
So I don't really know what advice should I give to you. Single WSP is more maintanable than buch of them, also if you are doing just some minor changes updates work perfectly. But if you need to make some bigger structural changes problems start to show.
I'll probably wait and see if people with more MOSS expertise can say something about this topic.
Basically (for the reasons you've mentioned), you should think of solutions as you would .Net assemblies - atomic units of code that can be deployed separately from others. Using upgradesolution will cause a redeploy of all the contained features - if nothing's changed, then nothing should change for the sites that use that feature. But, if that makes you nervous, consider splitting it up.
UpgradeSolution is really handy if you are just updating the assembly and leaving the provisioned files intact.
Unless you specify -local then upgradesolution will perform a full iisreset across your infrastructure. This is really worth noting for when you are planning the right time to perform upgrades.