we have created a feature ,which have got 2 application pages. one is to activate the user control and the other one is for database configuration,for the database configuration the user have to give the .mdf and .ldf files to restore the database. For the restoration of database we have used microsoft.sqlserver.replication.dll, the feature is working fine, but when we deploy it on any other machine, at the time of activation it gives error, and the error is:
Error: Cannot add the specified assembly to the global assembly cache: Microsoft.SqlServer.Replication.dll.
The feature is working fine with windows server 2008 but its giving the mention error with windows server 2003 .. any idea?
Does anyone know how to solve this?
Thanks
SAAD
Related
I have tried multiple ways to get the production SharePoint content to my newly installed local development environment that is running on a VM Windows Server 2008 R2. After an export of the farm and a restore failed I came across this blog post and followed these instrucitons: http://richardstk.wordpress.com/2012/02/03/build-a-sharepoint-2010-development-test-environment/. To sum up, it's basically backing up the live SQL Content database as well as the Profile, Sync and Social databases, then restoring them on the dev machine and pointing SharePoint to use these new databases instead of the old ones. Then after that I deployed the custom webparts to the development server from within Visual Studio.
I've done this and it seemed to work pretty well. I can access Central Administrator as well as setting up a SharePoint Connection within Visual Studio and being able to see all the pages, lists, documents, etc. So it is definitely pointing to the new content database. I should mention I can also connect via SharePoint Designer and access all the correct content, Master Pages, lists, etc.
The problem I am having is that I am getting a "Could not load file or assembly" error when I go to the site in a browser and it takes me to /Pages/Home.aspx. The file is a custom webpart that I have deployed from within Visual Studio. When I look within the GAC I see the assembly listed but the PublicKeyToken is different from the one that is shown in the error message.
When I dig into it a little more I see that the custom user control is registered in my Master page, and when I look at the ascx file in the _controltemplates directory where it is located there is an Assembly that looks like this:
<%# Assembly Name="BlogRoll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=529e9730fe2a198d" %>
That PublicKeyToken is correct for the live site when I look in the GAC there but when I deployed it to my local GAC it created a new PblicKeyToken. Sorry if I'm rambling but I wasn't sure what was relevant and what wasn't.
I guess my question is how to handle this? It doesn't seem smart to change all the ascx files locally to match the new PublicKeyToken's that I have in the local GAC because then when I deploy these changes to live they won't find the appropriate assembly. What is the best way to handle this?
UPDATE
The code in question has a key.snk file that is being used to strongly sign it. My understanding is that this should make it so that it gets compiled with a specific PublicKeyToken each time and therefore install in the GAC with a specific PublicKeyToken. If that is true, then I believe the only reason it would have a different key token on my dev environment versus the production is that the key.snk file that has been provided is incorrect. Is that true?
You could use WSP Builder or WinGac to forcibly deploy the assembly with the correct PublicKeyToken to your local GAC.
I'm trying to build a Web Deploy package via msbuild on a new machine and it's not working. It builds fine on other machines, but here I get the following vague error:
...\Microsoft.Web.Publishing.targets(2767,5): error : Filename: redirection.config
...\Microsoft.Web.Publishing.targets(2767,5): error : Error: Cannot read configuration file
...\Microsoft.Web.Publishing.targets(2767,5): error :
...\Microsoft.Web.Publishing.targets(2767,5): error : Unknown error (0x80005000)
I'm not sure what 'redirection.config' is, and the line reference to the .targets file doesn't help at all.
How can I fix this?
redirection.config is a file that lives in the IIS configuration directory, typically %SystemRoot%\System32\inetsrv\config. Here are two possibilities:
The account building your project doesn't have access to the IIS config dir. This might happen if you have an automated build identity with special permissions, or you if you need to start Visual Studio as an administrator.
You don't have IIS installed at all on the new machine. Check to be sure the IIS config directory, and redirection.config in particular, even exist. If not, you'll need to install IIS.
If you receive this error when deploying with Release Managment (via IISConfig.exe) be sure that the deployment agent service account is in the local Administrators group. You may need to restart the deployment agent service.
Similar Issue resolved below - Might help
Insufficient Permissions Problems with MSDeploy and TFS Build 2010
For me, simply running visual studio as admin gave it the elevated permissions it needed to operate against this folder.
May work for others.
I got this error when I tried to use a relative path for the contentPath setting. I fixed it by settings the contentPath to the full path of the folder. Without the full path, the contentPath provider thinks it is a site path or application path and looks for it in in the IIS configuration.
This error just appeared to me when my C# project was referencing the Microsoft.Web.Administration, Version=7.9.0.0 assembly. It looks like this assembly only works with IIS Express. For IIS, we must use Microsoft.Web.Administration, Version=7.0.0.0.
After hours of testing and troubleshooting this problem turned out to be an issue with the users profile.
This was found by logging in as myself and I didn't receive the same issue.
To fix this issue:
Log into the machine as an administrator and delete the contents of the corrupt profile from C:\Users (or rename the folder to username.OLD)
Open up the registry and navigate here – HKLM\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\ProfileList
Find the corrupt profile and rename this to .OLD or remove it.
You can read more about it at this article.
As this is high in search engines when looking for this error, I'll post my solution.
I used Azure Pipelines to release the app to IIS and had this error. My issue was that I mistakenly used Build Agent job instead of Deployment Group job when configuring the release pipeline.
On server 2012 this error can be caused by UAC which needs to be disabled via the registry.
This article explains why...
https://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
change DWORD "EnableLUA" from 1 to 0
I am currently having serious issues connecting to a FoxPro database using an ODBC connection from IIS7.5
The database is on another machine than the IIS server and is accessed via a fileshare.
When I call the webpage from IE on the IIS server everything works fine. When I call the webpage from another machine I get a '[Microsoft][ODBC Visual FoxPro Driver]Cannot open file' error.
The application pool runs as a domain user.
When I run ProcMon on the IIS Server and call the page, when it is called from the IIS Server it accesses the offending file and then a whole bunch of other FoxPro files for that database.
When I run the page from another machine, I get an ACCESS DENIED error when it tries to access the first file.
It is a CreateFile call for a file called Comp_W.DBC that fails.
I checked and it is the same user that is invoking these calls to the fileshare so it is not differing credentials that is causing the problem. I even went as far as making the app pool account a domain admin to see if that might sort out the issue but still the same problem.
I cannot move the database onto the same server as IIS. I have tried to run the web application on the same server as the FoxPro database but I hit different issues to do with the fact that OWA runs on that server, and the 32bit ODBC driver causes conflict with an OWA dll that is loaded as a global module. I really need it to run IIS on a separate server from the FoxPro database.
The server(s) do not seem to be running kerberos as the delegation tab is not present when you administer users.
Any help would be greatly appreciated.
James :-)
I'd use the Visual FoxPro OLE DB driver instead of ODBC, because it's newer, faster and won't conflict with OWA. That would let you move it onto the IIS server.
Past experience suggests that you haven't given the IIS user permission to access the folder where the DBFs live. When you run IE on the local machine, you're passing the credentials right through -- when you run it on another machine, I believe the anonymous user rules come into play. (Been a while since I had to debug this one, take it with a grain of salt.)
I am facing a problem while starting the websphere message engine for one of the application deployed on websphere. This application is getting deployed automatically as a part of the installation of Websphere Lombardi 7.2 express edition. It's using websphere 7 internally to deploy it. When I try to start the message engine from the administrative console of websphere I am getting following error:
The messaging engine ProcessCenter01.twperfsvr-twperfsvr_bus cannot be started as there is no runtime initialized for it yet, retry the operation once it has initialized. For the runtime to successfully initialize the hosting server must be started, have its 'SIB service' already enabled, and dynamic configuration reload enabled. If this is a newly configured messaging engine and it is the first messaging engine to be hosted on this server, then it is most likely the 'SIB service' was not previously enabled and thus the server will need to be restarted. The messaging engine runtime might not be initializing because of an error while trying to start, examine the SystemOut.log of the hosting server to check for error messages indicating the problem.
After restarting the server, the same error shows. Can anyone help me to to find what gets loaded as a part of "initialization of runtime"? Are there any config files etc. that I need to check to solve this issue? I am suspecting some missing configuration causing error to load the runtime for this particular application.
I too faced this issue today had to delete all the files under the message store
check the directory-file path mentioned in
Application servers > server1 > Messaging engines > XXX.server1-primaryBus > File store
Just Enable the SIB Services For the particular Server.
Example:Server-->Application Server-->click on Server Name-->right hand side we can see SIB services-->Check box the Enable services.
This will solve your problem
Recently I have faced the same issue when I rebuilt the jvms in UAT envt. After searching on web I found that because of the old messages saved in the message store(flat files in my envt) the messaging engines was not getting initiated. After deleting the old messaging store and restarting the servers it got initialized.
I have struggled with this problem too.
In our situation the problem was that the file message store location was used that was already created for a different (or old) message-engine.
If you add a busmember to the service-bus and use a file store implementation, then you need to supply the path for the store and log folder. Make sure these locations don't exist yet, other wise you will run in the problem above. The message-engine for this member will use these folders.
If you have a script for creating the message-bus infrastructure, make sure that when you delete the bus or remove message-engines, that you remove the file store/log folders for these, before you re-run your script.
Another possibility is that you are using a external database as a data store, and the user that is used for the connection is not allowed to create a database. You might find a ffdc entry like this:
DB2 SQL Error: SQLCODE=-552, SQLSTATE=42502, SQLERRMC=DB2ADMIN;CREATE
SCHEMA, DRIVER=3.61.65
Then you have to go to your database administration tool and give DB2ADMIN the proper privileges. Then restart the server or cluster.
Finally this issue is been resolved. I did not create the schema in SQL Server with same name as that of the username I gave to connect SQL Server during the installation of WLE 7.2
Please find details about this at below link:
http://www.ibm.com/developerworks/forums/message.jspa?messageID=14795282
I got a backup of a Sharepoint 2010 site that I created from our client's production server so that I can make some new changes to it on my staging server.
I can restore the site collection from the backup without a problem but when I try to create a backup of the same site on my staging server, I always get the error "Operation is not valid due to the current state of the object".
Before the error is given however, a small part of the backup file is created. If I try to run the Backup-SPSite again, it always fails at the same point and the corrupt backup files are always the same size.
Going through the logs it looks like the problem might be related to user permissions. I wonder if it's possible that the user permissions, user data, etc that came over from the client's production server are somehow screwing the backup process now because the same data cannot be found on my staging server.
The same error is mentioned here http://technet.microsoft.com/en-us/library/ee748617.aspx but UseSqlSnapshot parameter doesn't work anyway in my case.
I've been hitting my head against the wall with this problem and would appreciate if anyone has any advice on what might help! :)
The setup:
Windows Server 2008 R2
Sharepoint 2010 Server (no SP1 because it hasn't been installed on the client's production server)
Microsoft SQL Server Express Edition
Cheers!
The backup process started working after I checked in a file that had been checked out by a user on my client's production server.
I found out what file that was by opening the corrupted backup file and looking at the title of the last entry.