I would like to use Datacap Maintenance Manager to delete batches after successful completion of batches. To determine if Datacap Maintenance Manager is a good fit for the application that my team is building, I started following IBM Datacap guide to build Maintenance Manager application. One of the steps in the Maintenance Manager application guide is to expand 'Maintenance Manager' in Action library and add few Actions to functions defined in Rulesets.However, I am unable to find 'Maintenance Manger' in Action library. A quick search on the internet opened up a list of Action Libraries that comes with Datacap studio and 'Maintenance Manager' Action Library is one of them. Tried with different versions of Datacap and could not find 'Maintenance Manager' in Action Library. Am I missing something here? Any help is appreciated. Thank you!
Please follow the below link:
https://www.ibm.com/support/knowledgecenter/SSZRWV_9.0.0/com.ibm.dc.develop.doc/dcane100.htm
You can find it under the
NENU actions lib in latest versions.
Since 9.0.1 i guess.
Related
I recently inherited an application from a developer who is no longer with the company. This application restores SharePoint sites from backups and extracts metadata and files from lists in the site. The application runs on a SharePoint server and uses the Microsoft.SharePoint assemblies in C# and VB.Net.
The backups come to us from various outside companies, and some of them have custom features installed. SharePoint Health Analyzer shows a warning about "Missing server side dependencies". When I look at the report there is a lot of "[MissingFeature] Database [db name] has reference(s) to a missing feature..." etc. The previous developer was supposed to implement a check for missing features, but it is obviously not working.
How can I identify features that the restored site references, but are not installed on the farm?
Thanks!
RH
You can use SQL Management Studion and check Features and FeatureTracking tables to see list of features, its' IDs, titles etc.
But do not modify these tables.
To solve missing features error. You can:
1. install missing feature (if you have it).
2. try to remove it (probably will fail as you don't have it).
3. as the last chance option you can create empty feature with the same ID as missing feature, pack it in WSP package and install it.
Does anyone here know what could cause a new feature to not show up in the SharePoint UI?
The solution it is part of has been correctly deployed to the GAC and shows up in the central administration list of deployed farm solutions, the feature appears in the FEATURES folder of the 14 hive, yet the feature itself does not appear in the features list for the site collection, either in the UI or in PowerShell using Get-SPFeature.
Yes, the feature is correctly scoped, and no, it is not hidden. :)
Any thoughts or pointers would be very welcome!
Answer supplied on sharepoint.stackexchange.com, with thanks to Simon Doy. https://sharepoint.stackexchange.com/questions/73871/sharepoint-2010-feature-not-appearing-in-ui
Somehow, something had gone wrong with the installation of the feature, and neither the UI nor commands like Get-SPFeature revealed its existence, although the Install-SPFeature -ScanForFeatures command emboldened below displayed the missing feature.
"Check that the feature has been installed. For example, if you are
performing Update-SPSolution and a new feature has been added between
solution deployments then the feature is not installed by default.
To check do the following:-
Run SharePoint 2010 Management Shell from one of the SharePoint
servers Type Install-SPFeature -ScanForFeatures This will show you any
features that are available in the SharePoint Root but have not been
installed. You can install any missing features using the command :-
Install-SPFeature -AllExistingFeatures
See the following TechNet
Article for more information.
http://technet.microsoft.com/en-us/library/ff607825(v=office.14).aspx"
Look in central admin to see what site collection the feature is deployed to. Make sure in that site collection the feature is turned on.
Also, check the deploy job status to see if it actually finished.
Is there a on install event receiver? If it errors out, the feature will not finish installing even after the DLL is copied.
We have a very large solution project for our MVC structure where I work. I am trying to filter my solution explorer down to only relevant files with a custom filter. Microsoft has an article on making a custom filter here, but when I try to build the source code they give it says one of the .NET Framework namespaces is not available (I have already reinstalled .NET). The namespace that won't resolve is: System.ComponentModel.Composition. I am hoping fixing this will allow me correctly build a filter (there are 5 errors in the project total).
I definitely have the 2012 SDK installed (you won't make it far in the tutorial without it).
The Funnel extension may be what you're looking for:
Decrease solution loading and re-compilation times dramatically by filtering projects not relevant for the current task.
The extension loads just the projects defined in filters (load filters must be defined before using them).
You've to add reference to "System.ComponentModel.Composition" assembly. This reference is in framework 4.0.
If you've problem referencing or finding this assembly, refer to this answer:
https://stackoverflow.com/a/6310236/2617201
I have made a setup of a web application which could be installed multiple times in the same machine. I need to remove the sites created during installation at the time of uninstallation process. For this I wrote a custom action using a installer class.
Now, the problem is, if I have multiple installation of the same web application, custom uninstallation is being called only during the uninstallation of the last application.
Can somebody please help?
Thanks a lot in advance.
What tool did you use to author the MSI? What conditional expression did you use for the custom action?
My guess is you used a tool that abstracted you from this and that you are using component action states. It's not until the last client ( product ) of the shared component uninstalls that the component uninstalls and therefore the custom action is executed.
You should also know that installer class custom actions are known for their fragility. Using a WiX DTF ( Windows Installer XML, Deployment Tools Foundation ) managed custom action would be a much wiser choice.
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.