I extended the StockItem with a few user fields, then created a custom web service end point to extend the StockItem with my changes. That worked great until I added another field. The customization package contains the changes (I verified in the XML) but when deployed to my production system its ignored. The old web service remains.
Has anyone else experienced this? What am I doing wrong here?
Turns out, the publish feature "execute all database scripts" was needed to force the package to reload the revised endpoints.
Related
I’m experiencing an issue with customization projects in Acumatica 2017 R2 Build 17.203.0029.
Specifically, custom screens, while in my project XML, are not visible within the customization project browser nor can they be navigated to once published (which occurs without error). This only occurs on my staging server. Everything works fine in my local dev environment and even on a different instance of Acumatica. My local dev environment matches the staging server in every possible way (Acumatica version, other packages, etc.)
Older versions of the same customization project have been published before and did not exhibit this behavior. It’s only after I replaced the project with newer version of the same project that I encounter the missing custom screen issue.
As shown in the screenshot below, remnants of the custom screens are present in the Customized Screens window. And the ASPX files are present and shown in the Custom Files window.
Screenshot of missing custom screen data
When I compare the “Edit Project Items” objects between the staging the server and my local dev version, they appear the same.
It it possible that the internal customization or sitemap tables on the staging server have inconsistent data? Is there anyway to rebuild them?
The solution appears related to the users roles config. I had not assigned access rights to the custom forms. Doing so solved the issue. The custom screens are now accessible by direct URL and are shown in the customization project browser. Maybe this will help someone else.
I had this same issue when trying to Deploy the customization to another instance.
To fix it I had to go to the site manager and change the URL of the new page
from: "/Pages/SO/CustomName"
to: "~/Pages/SO/CustomName"
Once again another issue
I am trying to delete a site that i have created via a template and i am running in to
No available sandboxed code execution server could be found.
The template only contains a few columns programatically created along with some content types.
The CT's are also added to lists.
Anyone got any ideas?
I will continue to go through the ULS logs and hope someone saves me
Cheers
Truez
If you have empty receivers in your features and your solution is a SANDBOX one you should either switch it to Farm solution or check if your user code host service is running. Go to Services and check the "SharePoint 2010 User Code Host". Also check the "Microsoft SharePoint Foundation Sandboxed Code Service" service in the /_admin/Server.aspx It has to be running to support sandbox solutions.
I've a farm scoped feature which has an event handler. The feature is activated by default on installation. After I installed the feature I found that the FeatureActivated event has been raised mutiple times (I've three web apps in total excluding central admin and it is called three times).
Because of this the feature deployment is extremely slow (as I'm doing some webconfig modifications for each web application).
Any ideas?
I have had a similar problem in the past. I created a static flag in the FeatureReceiver that indicates if it has triggered before.
Dirty, but effective.
If you make it a farm scoped feature, then the first install we be easier, sure, but then in 6 months when you create another web application, the settings wont be applied automatically and likely forgotten.
If though, you make it a web application scoped feature with the property ActivateOnDefault="TRUE" in your feature definition, then the feature will be activated in all new web applications when they are created.
http://msdn.microsoft.com/en-us/library/ms436075.aspx
And i hope you are using SPWebConfigModification to make the web.config changes, otherwise if you add new servers to the farm, then the web.config mods wont be applied either.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx
Do you need these web.config changes for all the web apps ? Including central admin ?
The first change I would do is to make it a Web Application scoped feature and selectively activate on required web application.
Also, do not make it Activate by default on installation. If you are deploying through script, have a separate command for activation. That way, you can easily debug if the bottleneck is in deployment or activation.
Using the SharePoint API, how can I modify an extended webapp web.config file?
I have to do some changes in this file to specify the connection string, membershipprovider, etc... for using Forms Authentication.
Currently, I can change the "master" webapplication web.config file, but not the extended one.
Edited
I'm using Sp 2007. I'm already using SPWebConfigModification class to modify the parent webapp. Thoses modifications are propagated to the extended webapp. I have to change ONLY the extended one. But I don't find the way to do it.
What I'm trying to achieve, is to program a little wizard that:
Shows a WebApp list so the user can select one
Extend that selected webapp to a different zone
Configure that extended zone to use Forms Authentication
Thanks
I got an answer form a blog.
In your case , you need to write a Web Application scoped feature which after you provision your site using your C# app, it is deployed to the newly-provisioned site and in the receiver of the feature you inject the required web.config settings because in that context configuration API is obtainable , but again bear the following in mind:
If you don’t use SPWebConfigModification class and either use ASP.NET 2.0 configuration API or your own mechanism , propagating changes across the farm is YOUR RESPONSIBILITY. If this happens on an standalone installation then you don;t need to be worried about this.
So it cannot be done externally. We have to do a feature in order to acheve this.
Thanks
Quick answer: look into the SPWebConfigModification class. I am assuming you're using SharePoint 2007. The best way to learn about this is to dig into open source projects:
Google code search: http://www.google.com/codesearch?q=spwebconfigmodification&hl=en&btnG=Search+Code
This project on CodePlex looks like it's one big SPWebConfigModification: http://www.codeplex.com/ajaxifymoss/Release/ProjectReleases.aspx?ReleaseId=13360
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->