I have created a custom list in SharePoint 2010 programmatically. It works fine on my development machine when I deploy the project (that contains the list) to the SP site on my machine. I can see the list being deployed under lists. But when I package the whole solution and deploy the solution to test site on our test server on another machine the list seems to be missing on that sever (it does not exists under lists on that site).
There are some other custom lists within the project which are fine and are deployed properly but this one is not.
I finally managed to fix this mystery to my relief!
The problem was the feature that was supposed to put the list on the SP server, did not do its job.
When I first created the custom list in VS, I added it to an existing feature in the solution. But for some reason which I still cannot understand, the feature did not put the new list on the server. But when I created a new feature and added the list to it, it did put the list on the server when it got activated.
I compared the two features together. They both have the same properties. The only difference is the existing feature includes some more items to deploy and has an event receiver associated with it though the event receiver does not do anything that could prevent the new list from getting deployed.
I cannot understand this behaviour and would appreciate an input if someone can explain it to me.
I hope this will help other people who might come across this issue before they start banging their heads against the wall!
It is solution deployment type. Press F4 when in Package.package. Set "Deployment server type" to WebFrontEnd.
Related
Why do we need a list definition to create custom list in visual studio?
I can create a custom list using the UI without the need for visual studio.
So what is the advantage of using a list definition to create a custom list in visual studio?
The UI can only create a list on a single server, in a single site. You can't copy this list to a different server, eg. to deploy it from your development machine to the production server.
It's also difficult to use the same list in different site collections or web applications. While you can save a list as a template, you can only use this template in the site collection it was created in.
The only way to define a list that you can easily deploy to multiple servers is by creating a list definition. Otherwise you'll have to backup and restore your entire site from one server to the other, or use third party tools that will do essentially the same thing.
Deploying using a list definition can take seconds. Deploying by backup/restore can actually take days, as SP will only warn you that something went wrong only AFTER the entire restore process has finished.
Furthermore, there are form customizations that can't be done without modifying the actual list definition, eg. hiding columns. If you create the list through the UI you'll have to use a third party tool to make the modifications.
Would also add, when doing development, you will need a procedure to migrate your code from DEV ennvironment to Your UAT environmet and then onto Production envirnment
If you do this manually it will take some time, also there is always a risk you have not created it the same way.
using list definations will make sure it is the same on each environment
Having a problem deploying a list instance via a feature, which should really be a noddy task, I know. I have come across many a post with the same issue, but there is no resolution.
I created the list in the UI with content and views.
Exported the site template as WSP.
Imported into Visual Studio the list instance, pages module and property bags.
Copied into my new solution.
Deploy list instance as a site-scoped feature.
List deploys fine with content and views. However, I receive the following error when trying to add a new item: “Unable to find the default new form for list”. The same applies for editing items.
Strangely, deploying via a web scoped feature works just fine.
I am thinking that this is probably something quite simple but cannot see it nor find a satisfactory resolution.
Many thanks in advance.
I discovered almost the same thing this afternoon, and solved it. For some reason the schema.xml has an empty Forms tag. You need to replace it with the stock forms tag as described by Microsoft - I wrote it up here;
http://notes.jonbeckett.com/2012/04/20/missing-forms-schema-with-sharepoint-2010-visual-studio/
The Microsoft page I discovered it on is here;
http://msdn.microsoft.com/en-us/library/ms459356.aspx
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.
We are using an infopath form that when submitted is supposed to fire off a custom .NET workflow. Basically, the information within the form is used to create a new sharepoint site. What I am seeing happen is that the first time the workflow runs (which is automatic after the form is submitted), the workflow errors out. When I run the workflow manually immediately after it fails, the workflow runs fine.
this.workflowProperties.Item["Client Name"]
I've debugged the issue down to the above line where workflowProperties is of type Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties. The first time the workflow runs, the property listed above (and all others) are null. The second time it is run the client name property is as it should be (populated from the infopath form).
Another important piece of information is that this workflow was working fine for over a year and suddenly started not working correctly a few weeks ago for no particular reason. We were having some permissions issues the past month but I cannot see how that could be related to the workflow issue. The user I am logged in as is a site collection administrator. I use the same user to kick the workflow off manually (which succeeds). I do not think that the workflow runs as the user that is logged in though (when it is run automatically on form submission).
Another interesting wrinkle to the whole situation: there are a total of 3 custom workflows that the application uses. 2 were made in visual studio - one of these works fine and other is displaying the behavior described above. The last was made in sharepoint designer and is failing.
I'm willing to try just about anything at this point. I am on a dev server (which displays the exact symptoms as production) so I can try just about anything.
I'm guessing this has to do with the workflow being fired asynchronously from the commit operation that sets the fields values. Can you try and fetch the item explictly from the list instead of using the Item from the workflow properties. something like the following:
SPListItem l_item =
workflowProperties.Item.List.Items.GetItemById(
workflowProperties.Item.Id
);
i'm not certain, but it may be worth a try.
The other thing to keep in mind is the SPContext.Current object will be null if being called from an EventReceiver, but will be valid if called manually. It doesn't sound like this is the issue, but its something to be aware of nonetheless.
If the InfoPath forms are submitted from a Vista or Win 7 machine, you might face this issue of getting a NULL value for the fields in the InfoPath form. Try adding a delay activity with around 10seconds and see if your are able to get the value of the fields from InfoPath.
Refer to this link for more details: Why does my SharePoint workflow fail when the client is running Vista or Windows 7?
Try looking in your SharePoint Logs.
They are located under the 12-Hive in the LOGS folder - open up the latest and look for something with 'Workflow infrastructure' in it, maybe that can point you in the right direction.
The "solution" was to do an export and transfer to a new server. Basically just use STSADM to do the export operation and then import the same file on the new server.
SEE:
http://sharepointdogs.wordpress.com/2008/07/30/content-migration-or-backuprestore-in-moss-2007/
I was on the phone with Microsoft Support for hours on this issue - transferring to a new server would be my recommendation for anyone else that might encounter this problem.
I have some custom SharePoint site definitions that are deployed via SharePoint wsp solution packages. They appear to work fine. I can deploy them fine via the stsadm command line, and my C# code running in some features can also deploy sites based on them. My webtemp.*.xml files appear to be correctly placed in the 12\1033\XML folder when my solutions are deployed. My problem is that they just don't show up in the central admin app when I try to Create Site Collection. Why not? I don't even know where to look for this.
EDIT:
Hmmm.. About an hour later I happened to go back to the create site collection page and my templates were there. I'm not sure what was up... weird caching somewhere or something.
I also should have been more clear that these solution packages had been successfully deployed many times on my dev box, so I didn't expect there to be a problem (with the deployment aspect anyway) on this other server.
Many tasks in SharePoint are queued and then executed via timer job. An IISReset causes the web applicationt to be reloaded into memory and for configuration information for example the web.config to be reloaded.
To give SharePoint a "nudge" and cause jobs to execute you might try:
stsadm -o execadmsvcjobs
Do you have the publishing feature enabled? I read that content types can't be saved in templates, so they don't allow publishing sites to be made into templates. This is perhaps linked to why they won't show you the ones you already made.
Although I don't have access to a central admin to verify, this is the case from within my site collection.
Did you forget to run iisreset ?
This is needed for SharePoint to reload site templates.
If you use the Record Center as the template for your root website, templates (.stp files) in your template library will not show up when creating a new list.
There is some weird bug that makes this happen.
Here is code that you can try running in the SharePoint PowerShell. The return value for GetCustomListTemplates($web).Count will be zero if you have the root web made from the Record Center template.
$site = get-spsite("http://localhost")
$web = $site.RootWeb
$list = $web.Lists["TestDocLibrary"]
$list.SaveAsTemplate("MyListTemplate.stp", "MyListTemplate", "My List Template", $false)
$site.GetCustomListTemplates($web).Count
More information can be found at the following links:
http://social.msdn.microsoft.com/Forums/ar/sharepoint2010general/thread/c5455a27-360a-465c-91d5-f81beeac6789
http://sharepointrecordsmanagement.com/2011/02/