My team and I are using multiple virtual machines on our local computers to develop a Sharepoint Site and, as this is really not supported, we are running into problems:
I am attempting to use the in-house import/export features with the following commands:
-- Export --
stsadm.exe -o export -url http://localhost/ -nologfile -haltonwarning -haltonfatalerror -overwrite -filename ClintonAWAS.sharepoint
-- Import --
stsadm.exe -o import -url http://localhost/ -nologfile -haltonwarning -haltonfatalerror -filename CoreyAWAS.sharepoint
Everything seems to have been brought over properly including the DB connections, with the exception of one important detail: the .aspx files in the /pages/ virtual directory. So far, we have had to export/import them manually, file-by-file in designer.
Am I doing something wrong? Is there another way to do this? Can anyone suggest anything? Thanks in advance.
I'd generally avoid doing this sort of site copying between developers - solution package projects with source control works much better - but if you are stuck with this sort of environment you may find the content deployment wizard quite useful.
Another thing to check is if the pages are published - copying a site with pages that have no published version can get you interesting results.
Related
I've been developing a new SharePoint 2010 package in Visual Studio 2010. This is my first development project in SharePoint so please pardon my use of incorrect terminology.
Within the package/solution there are a couple of Features, a couple of custom web forms, and a workflow for the custom list type which is also within the solution.
To develop and debug I've been simply using the Build > Deploy Solution option from within Visual Studio to build the solution and then it would automatically connect to my sharepoint server and create the custom List, install the features, add the workflow, etc.
But when I want to make a change, say change the color of the text on the custom NewForm (mine is called MyCustomForm.ascx) then I click Build > Deploy Solution it deletes the custom list, deletes the workflow, deactivates and deletes the features and then re adds them all again. Thus I lose all of my list items.
In production if I need to modify the workflow I can't simply do this as we would lose all of our list items. How can I do this?
I've done days worth of research and nothing works. I've looked into:
stsadm -o upgradesolution -name SharePointProject1.wsp -filename ...
stsadm.exe -o execadmsvcjobs
with no avail. It says everything "works" fine (no errors) but doesn't update the custom MyCustomForm.
I've also tried manually editing the files in:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES
to no avail as well. I modify the MyCustomForm.ascx file and refresh the SharePoint site page and it hasn't changed.
Any insight would be helpful. I am doing all development on the server machine that is running SharePoint and have admin access if that helps. Thank you in advance for all of your help.
The list is deleted because the solution package that you're deploying has the list item in it so Visual Studio is "helping" by making sure that you get the lastest version of everything (even it it hasn't changed)
There are two approaches you can take to over-ride this behaviour
Set the deployment model to "No Activataion" this will result in the package being deployed and leaving previously deployed and activated feature in place.
Remove the list instance item from the package by double clicking on the Package in the Solution Explorer and then double clicking on the List Instance Item in the right hand pane.
Next time re-deploy the solution you not should have your existing list removed (I'm not 100% on the workflow association behaviour).
Of the two I'd lean towards option 2
I'm working in SharePoint 2010 and have been unable to deploy (or retract) my WSP without causing an IISReset. Here's my situation:
•The solution contains:
•Fields
•One content type
•A page layout based on the content type
•A bunch of images that go into the style library
•There is ZERO code in the solution
•I've manually edited the manifest.xml
•Removed the assembly, so nothing would get deployed to the GAC
•Set ResetWebServer="False" in the Solution tag
Still, every retract or deploy takes down ALL web applications on the server. Is there any way even to restrict it just to one web app? Thanks!
edit: additional info - I'm packaging up the WSP and deploying with powershell commands, but I get the same behavior even if I deploy through Central Admin.
try this in SP Admin console (with credential admin):
stsadm -o addsolution -filename "C:\yourwsp.wsp"
stsadm -o deploysolution -name yourwsp.wsp -url http://yourspsite -allowgacdeployment –immediate
stsadm -o execadmsvcjobs
I have created a feature and i am auto activating it whenever 'My Site' gets created.
I am activating it for the template SPSMSITEHOST.
This feature changes the Picture URL property of User Profile.
Now, the problem is my feature gets activated but it seems it does not execute the code by default and and does not change the picture URL property.
When i deactivate the feature and activate the feature again then feature works absolutely fine as expected.
P.S: I am facing this issue on Production server, surprisingly this work fine on Staging server , i mean the same code !!
Any help ??
Thanks.
Sounds like something becomes out of sync on your production environment. Could it be caused by load balancing?
Are you doing this through STSADM commands?
I would stick the following line after after each command:
stsadm -o execadmsvcjobs
This will make sure processing for previous commands is done before moving on.
If thats way off then I would think its something to do with:
a) The way you're activating the feature... if you're using feature stapling, are you sure that the latest version of your stapling mechanism is in place?!
b) Assuming you have some sort of feature receiver in your code behind. Are you sure there isn't an error occurring thats being hidden by a try catch? If there is then you need to see what the exception is...
If it works when you deactivate/activate the feature, that almost eliminates security issues.
Hope this helps..
After long investigating and search for this problem i tried to rearrange the features at package file depending on the features dependencies, it seems SharePoint activate these features one by one as it's arranged in the package file and this is worked for me :)
I'm using the SSRS 2005 Web parts to display my reports in a MOSS 2007 SP1 Portal. I have successfully installed the Web parts in my development, testing, and UAT servers using the following command: stsadm -o addwppack -filename path/to/RSWebParts.cab. But when I tried running the same command in the production server, it will give me the following error:
This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.
I know I usually will get this kind of error message when I tried to deploy my custom solutions having no Web application resources (such as web.config entries) to a specific Web application. But this is not my custom solution, it is an out-of-the-box SSRS Web part and it does have resources scoped to a Web application.
I tried to even use different combination of the command by providing the -url, -globalinstall, and -force switches but it still give the same error.
The configuration of the 4 servers are exactly the same, both from software and hardware perspectives. All other features are working properly on the production server.
I even tried to extract the cab file manually to the bin folder of my Web application, then modify the Web.config manually to include the SafeControl element (copied from the manifest.xml inside the cab file). But it gave me an error saying it couldn't find the resources file. Even though, I extracted the whole file, including the resource files in the bin folder.
Is there anyone who can help me resolve the problem? Thanks a lot.
I have resolved it with the following command and it worked successfully. Do not add any extra things. The following code copies RSwebparts.cab in C:\ directory.
C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\BIN>
stsadm.exe -o addwppack -filename C:\RSWebParts.cab -globalinstall -force
Cheers & enjoy
Have you tried all possible combinations of the command?
The following combination works well for all of the web part packs we install:
stsadm -o addwppack -filename path/to/RSWebParts.cab -globalinstall -force -url ContentURL
I have several custom web parts that I'm in the process of deploying to production. During this process I've found a handful of minor things that need to be tweaked in the various parts. To deploy the new code I create a new solution package, deactivate then delete the features, retract then delete the solution, then do it all again in reverse order with the new package. Needless to say, this can be time consuming. Is it necessary to completely remove a web part in order to upgrade it, or can a web part/feature/solution be upgraded in place?
It depends on what exactly is changing in your solution. There is an stsadm operation specifically for upgrading solutions, but it has some limitations as far as what it takes care of for, most notably the removing of old features and adding of new features. However, if all your new functionality exists in the webpart DLLs, running a solution upgrade will deploy your changes without need for you to do anything further.
http://msdn.microsoft.com/en-us/library/aa543659.aspx
We have used Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.3 - Mar 2009 CTP. It has given us some problems, but when you get used to it and make sure that you do things in the right order it works.
http://www.microsoft.com/downloads/details.aspx?FamilyID=FB9D4B85-DA2A-432E-91FB-D505199C49F6&displaylang=en
This tool automates the retact / delete / deploy / activate .... job.
Another thing that we try to do is to keep as little functionality in the web parts as possible. Move what can be moved to separate dll's, then it is often possible to upgrade just by coping in a new version of the dll.
If you are making minor changes to your web parts then you can just replace the DLL's if the assembly version remains the same.
Of course use some discretion here about what is a minor change and won't break anything.
See this topic for how to use FileVersion and AssemblyVersion correctly.
Basically you keep the AssemblyVersion the same for minor updates while the FileVersion changes with ever compile.
This is exactly how Microsoft do it with things like Microsoft.SharePoint.dll - the AssemblyVersion is fixed at 12.0.??? while the FileVersion changes with every hotfix/service pack.
Oh - I just read the "Production Part" of your answer this shortcut may be more appropriate for Dev/Test rather than QA/Production
use this
stsadm -o upgradesolution -name "WSPName.wsp" -filename "c:/WSPName.wsp" -immediate -allowgacdeployment -allowcaspolicies
and then run the sharepoint job
stsadm -o execadmsvcjobs
from the other hand you can update the dlls using SharePoint PowerShell command
Set-location "C:\Users\Documents\WSP"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Users\Documents\WSP\wspcustom.dll")