Currently, we are developing customization function in different project. And manually merge all the code into one, then publish it.
But it's lack of version control and conflict control, I just wondering is there any better way like Git for developing Acumatica customization?
Customization project can be saved to a folder using a structure that is friendly to source control solutions like Subversion, Git or Mercurial. To export the files, open your project and from the Source Control menu select Save to Folder:
The folder will contain all the different elements of the customization project:
The Open Project from Folder option in the same menu allows you to load/update a project that was retrieved from source control. Acumatica blogger Sergey Marenich wrote a detailed article on that topic which you may find at http://asiablog.acumatica.com/2017/02/customization-and-source-control.html
Related
Is there any way that I can create a template within forms to utilize for every user in the company?
For instance; let's say I have the Sales Order Screen (SO301000) and the Document Detail grid configured in certain way, that display different amount of columns than the default (either more or less columns).
For each user I want to use this template (and all the ones created) that I will apply when I add the new user.
I'l appreciate any guidance and help.
EDIT:
I provided answer for Form element ASP template below. Although reading your question again I think what you're trying to do would be more along the lines of automating grid column configuration. We call this feature Default Table Layout.
There's a feature request for it here:
https://feedback.acumatica.com/ideas/ACU-I-415
The feature has been shipped in version 2017R2 and is documented here:
https://help.acumatica.com/(W(1))/Main?ScreenId=ShowWiki&pageid=30f3229f-20f1-4055-9c03-e0fe3b37080d
Image copy of documentation page:
For ASP Form templates
There are two ways to work with customizations in Acumatica:
As a Customization Project, everything is done directly in Acumatica
instance through the web browser using the Customization Project Editor.
As an extension library (DLL file) compiled in Visual Studio which is then included in the FILES section of a Customization Project.
For method 1, I believe creating custom templates would be a bit of a hack and would not be officially supported, if someone knows otherwise please chime in.
For method 2, we ship the Visual Studio templates with the Acumatica Configuration Wizard (Acumatica ERP Installer).
Those templates are in the following folder:
My Documents\Visual Studio 20XX\Templates\ItemTemplates\Visual C#
The templates will be available for ASP.NET solution only. You can open Acumatica Instance Website as a solution if the website is already deployed:
When you open Add New Item dialog:
The Acumatica Templates will be available:
Those are standard Visual Studio templates so you can copy and re-use them to create your own. Microsoft documentation for creating user template applies and you can follow their guidelines. Note that working with Visual Studio and creating your own template is somewhat less user friendly than using Acumatica Customization Project Editor.
Acumatica T100 covers using Visual Studio to create customizations and would be a good starting point to learn the techniques involved:
https://openuni.acumatica.com/courses/development/t100-introduction-to-acumatica-framework/
For a team of 3 developers in an Acumatica project which uses the Acumatica Extensibility Framework (AEF) quite heavily, we are using Git as a source control. However, I am still not sure what strategy should we follow regarding creation of Customization Projects. Should we just use 1 Customization Project to be shared across all developers or should we divide Customization Projects per feature (or possibly per developer)? What are the implications of each approach? Is there any guidance by Acumatica on this matter?
We do a single customization project as we are working on a single product (multiple modules). Distributing the customization makes it easier as a single zip file vs many zip files. We use a powershel script to create the customization package outside of Acumatica which simply stitches all of the files into a newly created zip file. This way each developer can quickly make a customization package and load the latest as needed (again pointing to a single package as our preferred approach). Hope this helps.
I'm trying to create simple custom command (added in TOOLS menu option) to open the tool bar with custom control in VS 2013 using VS Package project.
I'm following https://msdn.microsoft.com/en-us/library/bb165987.aspx this guide but not sure why it's not working.
When I click on it, it opens tool window but without content under it. I want to show the MyControl.cs or custom control content under it.
I've tried a lot to find it out on Google but no relevent article found for same.
I've notice when I created new VS Package, it created "MyControl.xaml" file which loading it's data properly. I deleted that file and created new user control "MyControl.cs" which is not loading data.
Not sure if it requires VSIX project or VS Package. Is there any other way to do this?
Nothing in vsix development is simple at first. Try using this tutorial. It's from a series you can find here.
For you to show custom tool window content you have to extend the ToolWindowPane class and override the Window property returning your content as a IWin32Window. The tutorial fully explains it, and very well I might add, and the series is excellent even though it targets vs2010.
I have an event handler feature that I've built for sharepoint 2007 and have deployed by moving the DLL to the GAC and creating Feature.xml and Elements.xml in the necessary folder and then installing them using the stsadm commands. I'm looking to avoid doing all this and instead have a WSP file that I can run to install the feature automatically in a production environment.
Thanks
Here's how I would proceed to convert your unmanaged items into a managed solution package in Visual Studio 2010:
Create an "Empty SharePoint Project".
Set the deployment target. In Solution Explorer, click the project node and look at the Properties pane. Set the Assembly Deployment Target property between GlobalAssemblyCache and WebApplication. In this case, we'd leave it as the default GlobalAssemblyCache.
Note also there's a handy property called Include Assembly In Package. This is used to exclude your default project assembly from the output package. Why do you need this? If your project contains no code: for example, you're just bundling up some third-party DLLs for deployment.
Replace your SharePoint DLL references. Follow the steps in Adam Macaulay's article to remove the v14 DLLs and add back the v12 DLLs.
Add an Event Receiver item. Right-click your project and point to Add > New Item... and select "Event Receiver". Give the event receiver a proper name and click Add.
Configure the Event Receiver. Visual Studio will connect to your (2010) SharePoint instance, then prompt you with a wizard to walk you through what events you want to handle and for which item types. The end result is an Event Receiver item in your solution with a stubbed-out class that overrides the proper methods, as well as an Elements.xml file that is configured appropriately. If you have both of these files already, you don't really need to complete the wizard "truthfully"... just select the first option, click Finish and let Visual Studio create the Event Receiver and corresponding Feature.
Add your code logic. In Solution Explorer, expand your Event Receiver node to reveal the .CS class and the corresponding Elements.xml. Copy the contents of your existing files into those locations.
Configure the package feature. In Solution Explorer, expand the "Features" node and locate the default feature (Feature1.feature). This was created when you added the Event Receiver item. For clarity's sake, rename the feature to something logical, then double-click it to open the feature in design mode. You should see your Event Receiver has already been added to the right-most pane ("Items in the Feature"). Were there others, you could selectively add/remove items from the feature. Here is the place you set the feature scope between Farm/Site/Web/WebApplication.
Also importantly, while in the Feature designer, notice the Properties pane has a wealth of additional options to set on the Feature. These can't be accessed any other place, so keep in the back of your mind that is where to find them.
Lastly, if you click the Manifest tab at the bottom of the designer, you can preview what the feature manifest will look like. The manifest can be manually edited if need be (effectively disabling the designer), but I have yet to find something I need to do that I can't configure via properties.
Configure the overall package. In Solution Explorer, expand the "Package" node and locate the default package (Package.package). Just as for features, double-click the package to open it in design mode. This is the same UI that features use, allowing you to pick which features will be part of this package. Your event receiver feature should already be added to the right-most pane ("Items in the Package").
Again, same as features, while you're in Package design mode, the Properties pane will make available certain properties that can't be edited elsewhere. Most notably, it is here you should clear the value out of SharePoint Product Version.
Also, we have the same manifest preview available to us via the Manifest tab at the bottom of the screen. This is handy for checking things like SafeControl entries (if you need them) and the like. The Assembly entry should reflect the correct deployment target (in this case GlobalAssemblyCache) that was set on the project.
Finally, the Advanced tab allows you to specify additional assemblies/SafeControl entries to the package, which is helpful if you're bundling up additional DLLs to the default project DLL.
Build your project. Obviously we want to make sure it compiles!
Test the deployment. When I test, I deploy to my 2010 instance first (because it's handy) and double-check that everything has been installed as I expected: DLL in the correct place (BIN/GAC), appropriate Web.config entries created, feature installed at the right scope, feature activates properly, etc.
Package the solution. Point to your Build > Package menu item. The WSP will be placed in the appropriate output folder for the active configuration. Test deploy to your SharePoint 2007 instance.
Check out "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project" written by Adam Macaulay. I used this as a reference when I wanted to do the same, and the methodology works great. I've successfully converted a lot of our Visual Studio 2008 projects to 2010 projects, while maintaining compatibility with SharePoint 2007 environments.
I will make one suggestion: if you don't absolutely need the Visual Designer for your web part (i.e. your web part's output is made programmatically), then using the Visual Web Part template adds extra "junk" to your solution which I dislike.
Rather, in step 1 create instead an "Empty SharePoint Project", then right-click on your Project in the Solution Explorer and point to Add > New Item... and select "Web Part" (not "Visual Web Part"). You don't end up with the ASCX control and you can ignore the parts of Adam's tutorial that deal with updating the Register declarations.
This also has the added benefit of capturing the correct name for the web part files up front, so you don't have to rename a bunch of "VisualWebPart1xxx" files.
I need to transfer a reusable Workflow from the stage env. to the prod.
The workflow is associate to a list, so the list id is stored in the workflow.
Is it possible to transfer the workflow and change the list id to the list name with Visual Studio? (We have no SharePoint Designer access to the prod. env.)
Short answer: No
I tried several hours to fix a reusable workflow, which same as yours was associated with a specific list - I switched systems and the GUID changed --> Workflow was broken.
You can give it a try and rename the MyWorkflow.wsp to MyWorkflow.cab and extract that somewhere. The workflow files are XML based hence you can edit the associated list GUID with your favorite editor. Now you need to package your edited file back into a cab file, rename it to wsp and you can give it a shot. I tried exactly that and resented to just "re-clicking" (as it's SPD) my workflow (two screens come in handy here).
That's what I call "reusable" workflow... Next time do not associate your reusable workflow with anything to keep it reusable.
I would recommend creating an Content Type in a Feature and then base your list and your Reusable Workflow association on that Content Type. We had a project in December where we successfully used this method. I saved a Reusable Workflow as a template. I then deployed the Content Type solution package and the Workflow solution package to another environment. Worked like a charm.
There are tow alternatives for deploying workflow regardless the assigned content types
It is very simple just do the following:
Alternative One
Save the workflow as template
Go to the following path in your site
http://your_server_Address/SiteAssets/Forms/AllItems.aspx
Download the file as WSP
Go to the following URL
http://your_Target_server_Address/_catalogs/solutions/Forms/AllItems.aspx
Upload the WSP, and activate the solution
Go to the site settings, then Site Actions, then Manage site features
Activate the feature that is related to the workflow
If you click workflows under site administration you would be able to see your custom reusable workflow
Alternative Two
Save the workflow as template
Go to the following path in your site
http://your_server_Address/SiteAssets/Forms/AllItems.aspx
Download the file as WSP
Open your visual studio
Click add new project
Under SharePoint choose 2010
Choose Import reusable work flow
Follow the wizard
Project will be created and can be deployed
Note : Make sure your workflow is reusable and that it has no errors