Is it possible to specify (or override) the Deploy ApplicationName, database server, and database name for BizTalk projects? If so, how?
Unfortunately this data is stored in the btproj.user file instead of the .btproj file, and my client doesn't want to check the btproj.user files into the source control system.
(FYI - we are using BizTalk Build Generator from CodePlex.)
I've just reviewed the source on CodePlex. When I understood everything correctly they are generating
%AppName%.Custom.targets
%AppName%.Custom.properties
files. Within the properties file some properties are listed for BTS Database Connectivity
<BizTalkDatabaseServerName>.</BizTalkDatabaseServerName>
<BizTalkManagementDatabaseName>BizTalkMgmtDB</BizTalkManagementDatabaseName>
<BizTalkManagementDatabaseConnectionString>
server=$(BizTalkDatabaseServerName);
database=$(BizTalkManagementDatabaseName);
integrated security=sspi;
</BizTalkManagementDatabaseConnectionString>
<PipelineComponentsFolderPath>C:\Program Files\Microsoft BizTalk Server 2010\Pipeline Components</PipelineComponentsFolderPath>
You could easily override these Property values by using the commandline or by adding additional msbuild arguments in VS or TeamBuild using the Property switch
msbuild.exe MyBizTalkProject.proj /p:BizTalkDatabaseServerName=SqlCluster
The developer of this project should rewrite the default MSBuild.Custom.properties file to look like this
<BizTalkDatabaseServerName Condition="'$(BizTalkDatabaseServerName)'==''">.</BizTalkDatabaseServerName>
By using this approach the "." identifier (for local SQL Server) will only be used when no value for the parameter is given. Because with the current implementation the definition of the Property could! override you value passed from the command line. So be aware of that.
Related
We have a database project that we publish to our local database. I have introduced a new database type and along with that a sproc that depends on it. Since the database project will not build unless the type exists, what would be the recommended course of action?
I want the database project's publish to create the type first, then build out the sproc. This will eventually make its way to Test, Stage, and Production servers, so it's important that it works locally first.
A buddy of mine found it -- I created the script as a regular script instead of finding the correct Visual Studio template "Add New Item > SQL Server > Programmability > User-defined Table Type", so the build action was "none" instead of "Build" as it needed to be.
I've been doing some porting of old SSIS packages from a legacy system into a new system. I was running some tests only to see some kind of error output related to the ODBC connection with Code: 0xC0202009.
The package's two connection managers are both built with SQLNCLI11.1 as the provider.
I believe I can fix the error if I switch that to SQLOLEDB.1. Is there a simple way to do that without having to rebuild the entire package from scratch? Is there an XML file somewhere I can just replace the old value with the new one?
The only way is to open the package (.dtsx) file with a text editor (notepad, notepad++). And search for this property and replace it manually. (.Dtsx file is an xml file)
But replacing this property may cause other errors if each provider has different properties. So Take a backup of these packages before editing.
Take a look at this question it may help you (check my answer and the others. It will give you an idea on how a dtsx file can be readed outside of visual studio):
Automate Version number Retrieval from .Dtsx files
Visual Studio has a Database Project for Sql Server. This has a number of advantages: it hosts configuration settings, and database objects in one place. The .sql files are part of the regular .NET solutions - visible in the Solution Explorer and editable in Visual Studio. And they have a mechanism for generating a deployment script. With each individual database object in it's own file, the tracking of changes and source control is greatly simplified.
Has anyone had any success with using Database Projects with "non-SQL Server" databases? We use Sybase - which uses T-SQL and is very similar to SQL Server so I'm hopeful.
Or is there an alternative approach? I guess I could use a standard project (.csproj) and call a custom commandline application as part of the post-build to convert the .sql files into a deployment script.
Any ideas would be welcome.
Thanks
OK, I'll answer my own question.
I added all of our SQL objects to their own .sql files within a Visual Studio .dbproj project. However, minor syntactic incompatibilities between the Sybase version of RAISERROR and the Microsoft version of RAISERROR caused the validation code built into Visual Studio to get unhappy. The problem with the database project was that this actually caused a compilation error - which basically made it into a show-stopper.
So I scrapped that idea and added the .sql files to a standard .csproj project file. I then implemented some custom code that would load all of the .sql files, and aggregate them into a deployment script when invoked. I added a call to the custom code to the post build of the .csproj file so that whenever it was compiled - it would output a deployment script - which works like a dream with our build server.
In order to get some of the benefits of the .dbproj, I looked into writing a full SQL parser, but was quickly discouraged by some of the posts on SO. Instead I did some rudimmentary parsing with regex - which got me a few cool features without a lot of effort:
The code could detect dependencies between the various .sql files, and add them to the deployment script in the correct order to avoid sysdepends warnings.
Where there were no dependencies, objects were ordered based on the object type (stored procedure, function, grant statement, etc) and then by name so that the resulting script was always ordered the same - which is very important if you need to diff two versions of the script.
The deployment script can figure out some of the required permissions, so I don't need to keep track of all of the GRANT statements.
Stored procedures that are in the database but not in the script can be dropped automatically - so I don't need to keep track of what state each database is in - we just run the script and everything is in the correct state.
We have a few stored procedures that our automated tests call that shouldn't be deployed. The code can detect these and include them in a Debug build and exclude them in a Release build.
The custom code also generates a diff script that determines what changes the deployment script will make to a database and prints them out. This allows the person who is running the script to get an idea of what it will do. For example, the diff script might tell them that no changes will be made - so they don't need to run the deployment script at all - which is kind of handy if it saves them logging in at 3am to take a database offline and take backups etc.
So the end result is that all of my SQL objects are in separate files making them easy to work with in Visual Studio and manage under source control. For the first time since I started this job, I can look at the history in source control and tell what files have been changed (before this we had one enormous .sql file with absolutely everything in it).
I want to update service references in a Visual Studio 2010 solution by using SVCUtil because this solution has several projects and it's not good to get references refreshed one by one.
I'd like to know your point, because I've to be sure I'm going to execute exactly same command than one done by Visual Studio 2010, or even if Visual Studio 2010 doesn't use SVCUtil, an equivalent command to IDE's behavior.
Thank you very much.
The easiest way to refresh a lot of service references is to put all those in a dedicated project. Reference this project from all the projects that need to use them.
If a service reference needs to be updated, you will do it in one place only.
Some googling here and here shows the settings on VS 2008, although this will depend of course on your options in the Advanced options in the Add Service Reference wizard.
From : http://geekswithblogs.net, Dave Barrett, 30 June 2008:
Contrary to Visual Studio 2005, the Add service reference command in Visual Studio 2008 does not use svcutil.exe, but rather it's own built-in functionality.
Using a comparison reference between the two and my own analysis of the results, I came up with the following command to mimic what the command does in VS 2008 (keep in mind a few of these options, such as the /ct and the /l switches, were specific to my situation):
svcutil *.wsdl *.xsd /l:C# /out:Reference.cs /noconfig /s
/ct:System.Collections.Generic.List`1 /ser:Auto /tcv:Version30
/n:*,<NameOfYourNamespaceHere> /edb
I ran this in the folder where the schema files (WSDL, XSD) were located from a VS2008 command line.
Edit : Agreed - Never be afraid to drop and recreate service references from scratch. When working with version control like TFS, "update" service references there is often quite a mess as it figures which wsdl, xsd and disco files etc have been changed, added or deleted etc (and get filenames like SomeXSD92.xsd). Generally it is quicker to just drop and recreate them.
Johan's post is makes a good point (and can be used as part of a standard design pattern called Service Agent which handles the implementation of the client proxy).
I'm not quite sure what you mean when you say two tiers would need to reference the same assembly? If you are sharing type of the entities called in the service you would need to reference the entity assembly in most tiers anyway. For your Service Agent assembly project (which has all the service references) you can either re-expose the same Service Contract used by the WCF server or wrap it in a new interface.
Within an SSIS package I have a Web Service task which uses an Http Connection Manager. I need to set credentials for the connection so that it will authenticate with the remote web service. I can set these at design time, however I would like these credentials to be provided to the package using an XML package configuration file.
The problem is that the credentials for the connection do not appear among the properties that can be configured. I have tried setting this programmatically, but I cannot seem to access the credentials that way either:
Dim webConnMgr As ConnectionManager = Dts.Connections("My web service")
Dim webConn As Wrapper.ConnectionManagerHttpClass = _
CType(webConnMgr.InnerObject, Wrapper.ConnectionManagerHttpClass)
webConn.?
Any ideas?
SQL 2005 has very limited member properties for the ConnectionManagerHttpClass. Thankfully it has been addressed in SQL 2008 :)
MSDN - SQL 2005 ConnectionManagerHttpClass properties.
VS.
MSDN - SQL 2008 ConnectionManagerHttpClass properties.
According to this MSDN link, the public class [ConnectionManagerHttpClass] implements IDTSConnectionManager90, ConnectionManagerHttp.
Since we will assume you are using SQL 2005 (according to your Stackoverflow tags), you may want to check out the IDTSConnectionManager90.ConnectionString Property on MSDN as well.
Also check out the ConnectionManagerHttpClass.ConnectionString Property on MSDN, which implements IDTSConnectionManager90.ConnectionString and is overridable.
This should point you into the right direction. May the farce be with you.
Sounds like you need to assign the values in the configuration file to a variable in your package. You can then access the variable from your script task (Dts.Variables("VariableName").Value.ToString if I remember rightly!).
I have found no way to specify the credentials using a configuration file, or programmatically, but a workaround is to simply save all the credentials (as set in the designer) in the package, and then have different copies of the package for each different configuration. This is done by setting the ProtectionLevel of the package to, for example, EncryptSensitiveWithPassword.
This is obviously not ideal.
SQL2008 SSIS exposes these properties correctly; unfortunately 2005 is the environment I have to work with. I have worked around the problem by developing a custom component which allows the properties to be set.
this can be done by setting protection level to EncryptSensitiveWithPassword, and run the ssis with decrypt option