3

Background: We have a ClickOnce-deployed WPF app, that talks to WCF Services, which in turn both talk to our own SQL database and also to SharePoint via the Client OM. To set up the WCF and the ClickOnce, we have a Setup project, which takes in details about server paths and database connection strings from the installing user and fires an Installer class to do fun stuff like writing config XML and updating the ClickOnce strapper for that deployment URL and such.

We need to add some BDC Models to SharePoint via this installer, so that end users can use SharePoint list interfaces to configure some of the rarely-changed table values in our database. (As "one-click" an install process as possible is a requirement being imposed by the client.)

Including a BDC Model project in our Visual Studio 2010 solution, we can get a packaged WSP for our BDC stuff, which sounds great...
One problem with this, however, is that in the feature.xml that gets packaged into this WSP, this hard-coded line appears:

<Property Key="SiteUrl" 
    Value="http://BuildingWorkstationSharePointInstanceUrl/" />

Visual Studio won't build with the feature SiteUrl set to anything other than a SharePoint instance local to the machine (which is pretty lame), so we can't change that pre-WSP.

Furthermore, the .bdcm files themselves have hard-coded connection string information:

<LobSystemInstance Name="DatabaseName">
  <Properties>
    <Property Name="AuthenticationMode" Type="System.String">PassThrough</Property>
    <Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>
    <Property Name="RdbConnection Data Source" Type="System.String">DatabaseServer</Property>
    <Property Name="RdbConnection Initial Catalog" Type="System.String">DatabaseName</Property>
    <Property Name="RdbConnection Integrated Security" Type="System.String">SSPI</Property>
    <Property Name="RdbConnection Pooling" Type="System.String">True</Property>
    <Property Name="ShowInSearchUI" Type="System.String" />
  </Properties>
</LobSystemInstance>

This would also have to be re-written by the installer once the installing user has provided the database connection information.

I'm also not sure what the best approach will be for actually installing the WSP on the server via the MSI (trying to execute a powershell script is all I've thought of so far).

It seems to me like designing BDC models for a third party shouldn't be that obscure of a scenario, but I can't find any information or support on how to overcome any of these problems!

Anyone have any advice?

Grank
  • 5,242
  • 7
  • 33
  • 36

5 Answers5

1

I ran into this issue as well. I'd like to package our BDC model into a WSP and deploy it via the WSP. Unfortunately (like you've indicated) the BDC model contains specific environment information that must be configured per environment.

What we've landed on is keeping the different BDC models and just importing them instead of packaging them in a WSP. From the sounds of it, you may need to ask for the specific environment information at the time of install and somehow use that.

Doug Stalter
  • 733
  • 4
  • 11
  • Taking your team's approach and not using a WSP package, you just have .bdcm files loose then? And then you can import them by running a PowerShell script I guess? – Grank Jun 01 '11 at 16:42
  • I recently found out that you can configure this within Central Admin. You can also maintain a separate resource file for the model that contains this information too. Within Central Admin, go to the BCS service app. Select "External Systems" in the drop down in the upper right. Click on your external system. Then click on the external system instance. – Doug Stalter Jun 01 '11 at 18:11
  • I ended up crafting a parameterized PowerShell script to import an all-inclusive .bdcm file. This had the advantage of being able to do interesting things like: write the connection string to the model, ensure BDC Service running, create BDC Service App if necessary, ensure Secure Store Service running, create Secure Store Service App if necessary, create Secure Store Service App Proxy if necessary, create Secure Store Service Target App if necessary, update keys, set the permissions on metadata store, create external lists for all entities in the model... :) – Grank Feb 15 '12 at 18:22
1

Two methods you could employ:

  1. If you're using a "Custom" assembly type (instead of a DotNetAssembly as your LobSystem Type), you can implement IAdministrable to allow you to change properties (either the LobSystem or LobSystemInstance) in the Central Admin. It doesn't seem to work for DotNetAssemblies, even if IAdministrable is implemented.

  2. Alternatively, you can change properties by importing Resource Files. Easiest way to do this is to import your model, then export it as a Resource file and edit the file down to the properties you need changed. Then import the bdcr (resource) file and you'll see an indication that the properties had been changed.

John Conde
  • 217,595
  • 99
  • 455
  • 496
1

Advanced Installer offers some support for this. Basically, through its XML editor you can use Windows Installer properties instead of hard-coded values in your manifest files.

The other solution I can think of is to use a custom action to modify the files after install.

Either way, this requires a complex installer, like an MSI package. ClickOnce doesn't support it.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
0

In our case, we implemented a custom Feature Receiver using instructions located at SharePoint 2010, deploying a BCS Model using a farm property bag to have a dynamic siteurl It allows to deploy in any environment because the Site Url is discovered during the feature activation.

  • It would be valuable if you included a summary of the solution within your post (with the link provided as a reference) in case the original page disappears in the future. – Tim Radcliffe Feb 11 '15 at 14:47
0

If you want to deploy your BDC to a specific siteURL when you deploy it, go to your project folder for your bcd model when you view your solution and in the properties of the folder you should see something called "Feature Properties".

Click on the elipsis to expand the properties and add a heading called "SiteUrl" and set it to be the root of the site you want to deploy it too: i.e "http://spsite".

It will be deployed to that site instead of the Local one.

John Conde
  • 217,595
  • 99
  • 455
  • 496
  • The issue is that the SiteUrl is hard-coded into the packaged WSP and it's not supposed to be known to the developer, just handed over to the client for them to install at whatever SiteUrl they see fit. – Grank Jul 27 '11 at 04:18