I recently migrated MOSS 2007 site to sharepoint 2010. The MOSS 2007 site included a custom application page. With IP address this page is working fine. I have deployed the dll in gac and placed the necessary forms in layouts folder. But using Internat or intranet dns I am getting below error:
An error occurred during the compilation of the requested file, or one of its dependencies. The type 'AjaxControlToolkit.SliderExtender' exists in both 'c:\Windows\assembly\GAC_MSIL\AjaxControlToolkit\3.0.30930.28736__28f01b0e84b6d53e\AjaxControlToolkit.dll' and 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\e2b85a3a\aefa6379\assembly\dl3\6cf6a9f3\d0ee2c06_53facd01\AjaxControlToolkit.DLL'
If I delete the dll placed in Temporary ASp.net folder it says not able to find the dll in the temporary folder url. N if i delete gac dll it looks for the dll in gac n throws the same error of unable to find.
I have provided below ajax entry in web.config but its still showing me the same error.
<add namespace="AjaxControlToolkit" assembly="AjaxControlToolkit, Version=3.0.30930.28736, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" tagPrefix="ajaxToolkit"/>
</controls>
and in tag i added the assembly entry
Try replacing your Ajax Control Toolkit which is compatible with .Net Framework 3.5.
As you have migrated from MOSS 2007, your existing Ajax Control Toolkit might be compatible with .Net Framework 2.0 only.
Related
I have a published web application on specific server. I want to run the same application on another IIS server, but i get this error
Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies. Access is denied.
Exception is here
Installing Report Viewer fixed it.
The problem was that my web.config was targeting .NET 2.0 and has some configuration related to .NET 2.0. I've updated the solution projects to target .NET 4.0 which need the report viewer dll in GAC folder or something global and that's what report viewer installer will do.
I am a system admin tasked with migrating Classic ASP based web application from Windows Server 2003 (IIS 6) to Windows Server 2008 r2 (IIS 7.5)
The application is very old written in around 2002-03 and the concerned developer people are not around anymore to let me know anything related to this Web Application.
After lot of trial and error, I have been able to get the Web Application running on 2008 r2.
While navigating through application, I am getting various errors which on further investigation I understood are related to DLLs which the Web Application is invoking.
My issue is, I don't know what all DLLs are used/invoked on the source server, which I need to copy & register on the new server.
I tried to use DependancyWalker but I am not able to find a way to use this tool for Web Application.
I would really appreciate this community's help in this regard.
I found out a simple way of finding the DLLs which are specific to my Web Application.
I got a small freeware utility called as RegDLLView from Nirsoft.net which lists all the DLLs which are registered with the Server with File Paths, Description, Company name, etc details.
I found out all the DLLs which my Web Application is invoking by checking the company name and paths of all the DLLs which were listed.
Now I just have to copy these DLLs to my new server and register these on the new system.
It's not rocket science.
When you find a COM component dependancy you can use the ProgId to identify and locate the DLL which is registered in the Windows Registry.
The only DLL dependancies come from COM component DLLs and these can only be invoke in Classic ASP / VBScipt with the
Server.CreateObject("ProgId")
and
CreateObject("ProgId")
respectively.
Wrote about this extensively here
Error ASP 0177: 8007007e Server.CreateObject fails for COM DLL
I have written a Custom URL Rewrite Provider. I am able to successfully use it on my local system. However, on the staging environment I am unable to get the dll to list in the "Managed Types" dropdown when I try to add or edit the provider. The dll is successfully added to the gac using gacutil.
The URL Rewriter Dll is built using Visual Studio on my local machine. On the staging environment it is normally built using MSBuild/Jenkins but to be sure, I also built it using Visual Studio.
However, UrlRewriteProvider.dll does not show up. Both the site and the dll use .NET framework 4.5.
How can I fix this?
I am getting the following error while trying to load an ASP.net website on IIS.
I created a virtual directory for the website, and though my website contains no reference to any assembly ( I even tried a blank ASP.net website with 1 button) but still with no use.
I am using Windows server 2003 64-bit edition.
Could not load file or assembly 'Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
This could be available in your web.config file under <assemblies> and hence IIS is trying to load it.
In addition you can download report viewer installer from HERE and then try to run your website, it should work once this assembly is available in GAC.
I'm trying to publish Browser Enabled Infopath Forms to the SharePoint sever but, at the end it was showing me the following Error:
The SOAP response indicates that an
error occurred on the server:
Server was unable to process request. ---> Method 'get_ServerInfo'
in type
'Microsoft.Office.InfoPath.Server.SolutionLifetime.XmlFormProxy'
from assembly
'Microsoft.Office.InfoPath.Server,
Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c' does
not have an implementation.
Do you have Infopath 2010 installed?
WORK-AROUND: The issue appears to be associated to having the new Office 2010 beta products installed and specifically InfoPath 2010. I am investigating the assembly conflict but the easiest work-around for now is to simply uninstall InfoPath 2010 (beta) and re-run psconfig again (you should not need to uninstall any other 2010 beta product and this will likely be a non-issue at RTM).
Source
This appears to be also an issue with Office 2010 RTM. I just experienced the exact same problems using office 2010 installed on a fully patched MOSS 2007 farm.