What happened to kernel.Scan in Ninject 3.0?
kernel.Scan(scanner =>
{
scanner.FromAssembliesMatching("LR.Service.*");
scanner.FromAssembliesMatching("LR.Repository.*");
scanner.BindWithDefaultConventions();
}
Get a build error.
'Ninject.IKernel' does not contain a definition for 'Scan' and no extension method 'Scan' accepting a first argument of type 'Ninject.IKernel'
Been banging my head for hours trying to figure out what to change it to.
Have not seen any good site or posts explaining how to fix this simply.
This all was working perfectly fine, some piece of ninject got upgraded. After hours of figuring out why nothing was working. I did not reinstall it(knowingly), not sure what happened, but now I've reinstalled everything to 3.0, figured it woulf be better, now I'm stuck with a lack of any help.
Will be checking out this later. Think this is what i was looking for.
http://sharpfellows.com/post/Ninject-Auto-registration-is-changing-in-version-3.aspx
UPDATE:
See out my other ninject3 question on auto discovery
Ninject 3.0 MVC kernel.bind error Auto Registration
I ran into a very similar issue recently because of some library documentation incorrectly referenced “AutoLoadModules”. I had a hard time finding out this was actually a thing from the past. And half of the accepted answer is now a dead link. So in case this can be useful to someone else…
There has been, with NInject3, several breaking changes around Ninject.Extensions.Conventions.
So if you are looking for AutoLoadModules, IKernel.Scan and the like, tough luck.
Instead, you are now left with only IKernel.Bind extension method:
_kernel = new StandardKernel();
_kernel.Bind(s=> s.FromAssembliesMatching("LR.Service.*", "LR.Repository.*")
.SelectAllClasses()
.BindDefaultInterface());
Related
Trying to post to CocoaPods, but when the project goes through it doesn’t generate docs (site + docs button, instead of expand). Alternatively, when I specify a docs url the docs button doesn’t work either. According to the guides, it seems like jazzy isn’t parsing, but when I run:
jazzy
or...
jazzy —podspec MagicCloud.podspec
…it throws no errors and generates 100% documentation (which is hosted here). At the 404 page, If I select the Alternatively, click… or Potential error info buttons no luck. I’ve tried with and without a .yaml file generated here. When I try to use the following…
http://api.cocoadocs.org:4567/redeploy/MagicCloud/2.9.x // x = 5,6,7,8,etc…
http://api.cocoadocs.org:4567/error/MagicCloud/2.9.x // x = 5,6,7,8,etc…
…safari can’t find the server. I’ve posted so many versions at this point, any help would be much appreciated. The project is here, along with it's podspec file. Thanks in advance.
So after contacting Orta (the developer) directly, I eventually found out that he had handed the project off to Buddy Build. With their acquisition by Apple, they're holding off on new clients and are no longer offering support to Cocoapods.
As far as I can tell, no new Cocoapods have been able to compile their docs (at least through jazzy / swift), since the announcement January 2018. If anyone knows different, or if things change, please post here. Thanks.
I recently asked a question about ripping models out of the core ASP.net MVC 3 application and putting them into a class library. See question.
Which was then answered by stating I have to re-install MVC.
well after spending all morning doing that, I got everything to work, accept for one thing: System.Web.MVC which is needed for [Compare] before the reinstall, things like web.secutiry, system.componentmodel.dataannotation were not working but they are now.
The only thing not working is Web.MVC is this going to be yet another reinstall?
I make extensive use of the CoffeeScript Maven Plugin which used to live here: https://github.com/iron9light/coffeescript-maven-plugin. (if that link is no longer 404'ing then it must have come back; consider the question answered!)
It seems to have disappeared which is odd as it's always been there in the past. I have local copy so it's not a mega problem but I would be sad if the chap who maintains it has deleted it / stopped maintaining it!
Does anyone know what happened to it?
Huh, it's back now! I guess it took a little holiday. https://github.com/iron9light/coffeescript-maven-plugin
Recently CI 2.1.0 is out.
I have a question. As I recognized that the CI folder structure has been 'evolved' (easy to setup, automatically defines base_url,etc), I'm wondering if the current template libraries like Phil's,william's concept,ocular,etc.. can be adapted to this new CI version.
I've tried Phil's but no luck, I mean..I don't know if I'm missing something this time, and ocular, also, to no avail ( I don't subclass the Controller, as suggested here)
Any better templating suggestions that will be suited enough to the latest CodeIgniter 2.1.0?
Thanks.
It seems like from the comments above that you're having trouble finding any resources online on the matter. Here's my suggestion for you:
Check the CodeIgniter Change Log here, and compare all the changes between this newest release, and the release that you know last worked with the template libraries that you've mentioned above. Use deductive reasoning, and see if you can find a way to modify the templates you need to work with the current CodeIgniter structure. I know that's a lot of work, and is not ideal for your situation. Regardless, it's the best advice I can give at the current moment. Good luck, and happy reading!
Internet Explorer 9 was released today, and I decided to check a few Magento sites we build in the last couple of months to see if everything continues to work with the new version.
But unfortunately it doesn't. I came across one particular problem that is caused by the version of the prototype library which is shipped with Magento, version 1.6.0.3.
It looks like the cancelling events in eventhandlers isn't working.
For example, if you try to log in to a Magento shop, and just leave the login and password fields empty, IE9 submits the form even if there were errors, and the errors disappear after the refresh.
So that's quite a big problem I think.
So my question is: how can we deal with this problem? I see a couple of ways to deal with this:
Wait for Magento to release a new version with fixes
Upgrade the prototype library to the latest version which probably already has fixed the issue
Mess around in the existing library and try to fix the bug in there
Waiting for a new Magento release isn't a good idea because it probably will take a few weeks before there is one, and because it will cause a whole lot of other problems if you are running a very old version of Magento.
Upgrading to the latest prototype library is probably the best idea, but will everything in Magento continue to work with the latest version of prototype, does anybody has any experience with this?
So what's everybody's opinion about this problem?
Any ideas other than mine?
As upgrading Prototype has the potential to break a lot of things in Magento (and, honestly, doing anything in Magento has the potential to break a lot of things in Magento), I created a theme override for my
app/code/design/frontend/{package}/{theme}/template/page/html/head.phtml
file and slapped the following as the first element under the head tag:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
This tells IE to pretend as if it is IE 8, where possible. This solved an issue where, for example, you could not check out and complete the payment process if you only have one payment method enabled, as in IE 9 the fields will all be grayed out.
Note that it really must be the first tag underneath the <head>.
Since upgrading Magento in any way has the potential to cause problems, I feel this is the least intrusive way to solve the issue in the near term.
Solved: http://www.alexanderinteractive.com/blog/2011/10/solving-the-ie-7-ie-9-magento-prototype-validation-bug/
I spent a couple days on this, and discovered the only thing that truly works is disabling things at the form level. This should solve all your problems.
As a quick fix, I think I would take the same approach you are advocating, and upgrade Prototype to a version that does not contain this issue. However, Magento will be coming along with a patch (this is too big to ignore), and at that point, it would be wise to undo your changes and apply the patch they provide to keep in line with normal upgrades.
It is rarely worth it to manually dig in the internals of Magento's JS, so that option seems a bit off to me. There are probably several places where this semantic is used and you may miss some of them.
Hope that helps!
Thanks,
Joseph Mastey
I've updated the prototype.js file to 1.7 and so far it's correct. I dont see any errors. If you apdate and find errors please notify!
The proper fix is in the Magento forums.
In template/catalog/product/view/tabs.phtml, change the line that reads:
ul.select('li', 'ol').each(function(el){
to
ul.select('li').each(function(el){