I am trying to Configure an IOC Container using SOLR as my search engine for sitecore but after many attempts the configuration gets stuck at a castle windsor error. I have attached the error image below and yet I am not able to change the assemblies as required. HELP!!
Solved the issue!! As per point number 11 of the blog extract Castle.Windsor.dll and Castle.Core.dll versioned 3.1.0 (links provided in the blog itself) and paste it in your website bin directory. This will eliminate the error.
Related
I am trying to find some guidance on where to go next on the issue I am having migrating a phpbb3 site from one hosting service to another.
I have checked to make sure the config.php file has been changed to work on the new server, as well as the common.php file. I am getting a HTTP 500 error when I try to search for the forum. The main site is working normally, just the message board is having a problem.
Nothing about the structure of the sites pages has changed, only the hosting server. (I downloaded a copy of the website before moving it so I have everything in the exact way it was before, just on the new server.)
Do I need to install phpbb onto the server itself with Softaculous?
Anything would help, I need to get the site back up and running soon.
Thanks in advance.
Jacob
This post would have been better addressed on phpBB.com support section...
In any cases most hosting companies out there will perform the migration for you for free.
Did you ask about handling a migration for you?
There are many things that need to be done when migrating to a new hosting.
here a couple of pointers for you:
-PHP version in use should be PHP 5.6.x as phpBB 3.0.x does not support higher PHP versions
-config.php might need updating, for example these two fields:
$dbhost = '';
$dbport = '';
-check your error logs in your cPanel as they will reveal the cause of the 500 error
Also, NO you do not need Softaculous
I'll be happy to help you with this if you PM me on:
https://www.phpbb.com/community/memberlist.php?mode=viewprofile&u=1428301
-SiteSplat
The php version on the new hosting services server was above what phpBB 3.0.x needed. I upgraded phpBB to version 3.2.9 and the issue was resolved.
I have followed the imageresizer's troubleshooting for when images do not appear as they are listed here:
Potential causes:
You are using the .jpg.ashx syntax, and you did not register the HttpModule properly in both places of your Web.config file.
You are using the .jpg.ashx syntax, but you're not using a query string. You should drop the '.ashx' unless you actually want to process the file.
You are using ASP.NET MVC, but do not have the MvcRoutingShim plugin installed.
You have Precompilation enabled, and are using an image provider. This is caused by a long-standing bug in the .NET framework.
However, everything works perfectly in my local development environment. I have the MvcRoutingShim plugin installed and all the correct web.config references. On the live site, all images referenced by either just a querystring OR the RemoteReaderPlugin.Current.CreateSignedUrl procedure are not found.
All images are resulting in a 404 error.
Any ideas?
The answer: DiskCache(ConfigurationError): Not working: Your NTFS Security permissions are preventing the application from writing to the disk cache
Please give user read and write access to directory "C:\inetpub\wwwroot{site}\imagecache" to correct the problem. You can access NTFS security settings by right-clicking the aformentioned folder and choosing Properties, then Security.
I have a WCF service project hosted in IIS. The main SVC file is in the root of the web application folder, and in the bin\ folder are the actual dlls. The web.config (also in the root) contains all the unity mappings. Unfortunately, it seems that because the concrete assemblies etc. are living in the bin\ folder, Unity cannot find them.
Is there a way in the Unity configuration file that one can specify a path (sort of like probing) where the DLLs might live - or to put the path inside the mappings themselves somehow? I don't want to actually have to modify the probing paths in the machine.config etc. if we can avoid that.
I've looked on MSDN and Googled around but couldn't find anything of help.
Any ideas?
I too doubt this is a Unity issue. Have you tried using the Fusion log viewer, FUSLOGVW.EXE, to see what the application is trying to load and where it's looking for the assemblies?
http://www.ademiller.com/blogs/tech/2008/01/gotchas-fusion-log-viewer-your-best-friend-for-assembly-load-errors/
This should tell you what the current probing path looks like and you can take it from there.
This wasn't a Unity issue in the end - it was more that I was trying to host the application within IIS and had to configure that correctly.
I am currently working on Axis2 deployed on Resin 3.1.3. However, I got the below error during deployment:
org.apache.axis2.deployment.DeploymentException: The "Dispatch" phase is not found on the global "InFlow" phase of the axis2.xml file. Make sure the phase is within the axis2.xml file.
Any idea how to resolve this? Thanks in advance for your valuable help.
-Angel
Have a look at this page, underneath the "Phase Order" heading. That should let you know how you need to define the Dispatch phase in your axis2.xml.
It's also possible that the axis2.xml file can't be found or is missing. You haven't provided many details so it's hard to be more specific than that.
Edit:
Remember that Axis2 is a standalone web application that is deployed into a servlet container.
You indicated in your comments that you modified your web application's web.xml. You should not need to do that to get Axis2 to work properly, so you can remove those mappings and redeploy your applications.
Try this guide. Make sure that you can see the "Axis2 Happiness" page described in step 6.
Once you have that working, you can go back to your other web applications and start modifying them to call your web services.
I have a Windows application in .Net 2.0 that uses several levels of configuration files. For reasons out of my control, the application consists of a Windows app (.exe) project and several DLLs, each of which has its own app.config file.
I have successfully figured out how to read the config file for each DLL, using (in C#)
ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None);
This works just fine - I can confirm that I get a Configuration object from this method when pointed to the file path name of my DLL's configuration file ("foo.dll.config"). However, when I try to access a custom configuration section, I get an exception saying that the data type for my custom configuration section cannot be found.
What else do I need to do to get the typing information available to my code when loading a configuration file in this manner?
It's unfortunate but true: the way to handle this is to copy the configuration from the .dll.config files into the applications' config file. The only exception has something to do with the Settings system used in Windows Forms. I think that does the OpenMappedConfiguration for you, but I'm not sure.
I've never known why they didn't unify this in .NET 2.0 and solve the problem. Maybe I should ask.
Earlier in the day, I asked a question like this as relates to WCF, in the Oslo Forum on MSDN (http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044-b1f0-43ad72fb508d). As I was searching for a blog post or some other answer (as I said above, "maybe I should ask"), the answer to my Forum post arrived.
Long story short, and somewhat tongue-in-cheek, the answer is: they didn't fix this in .NET 2.0 because they were waiting for Oslo to solve the problem.
Without trying to avoid downvotes by making sense out of that, I'll just mention: Oslo will encourage models of applications and application components to be stored in a central repository. That will include models of per-instance configuration. The theory is that all such data would be stored in a single repository (at least per-system). So, no more question of where the configuration file is located it's all in one place. No more question of finding the assembly containing the configuration section metadata - the metadata is stored in the repository along with the configuration data.
Ask me tomorrow, and I may feel differently, but right now, I may be picking up the Oslo religion...