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.
Related
I need to include a Stored Procedure in Visual Studio 2013 which references another Database which is not part of the solution. I only refer to a very small portion of the external database which is itself big and complicated.
I know I need to add a reference to it so that I don't get warnings when referring to objects within the external database from within the Stored Procedure.
Adding that Database to a this or another Solution is not an option as its not part of our solution and importing that creates a whole variety of other issues.
I can see in older versions of Visual Studio that I need to create a schema file using VSDBCMD but this has been replaced by SQLPackage, but I can't see how to access that and whether it will need the external database anyway.
I've been going round in circles on this, so some pointers would be warmly welcomed.
I realize I am late to the party on this but perhaps it will still be useful to someone: You don't mention if this is a c# project or a database project.
I'll assume database as I not sure how you'd get errors otherwise on the internals of an SP.
The only way I know of to remove errors on cross-database references is to add the other database as a project in the database solution, add a database reference to the project with the sp, and then instead of using Database.schema.table syntax in the sp change it (in the database project) to [$(database)].schema.table
Alternately, a DACPAC can be created on the referenced database and used instead of referencing the database in an added project.
I'm new to this stuff myself, but I work with a lot of database cross-references in my sps so I am working through how to address this in database projects
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.
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 have some event handlers which are tracking list items in my SharePoint lists. I would like to Audit the use of these in an external database (SQL 2005) outside of SharePoint.
What is the best practice for doing something like this? I can't find many examples of this being done but it seems like it would be something that is done frequently. Would love to get pointed in the right direction on this one!
Normally to get a DB connection in a .net app, I'd create a connectionString in the web.config. Should I be modifying the web.config for the web application that the code will run on?
It would be handy to be able to use LINQToSQL for my DB inserts/updates - is this possible from within SharePoint code?
Thanks
I am not sure I understand your auditing question fully to comment on it.... There is built in auditing functionality that you can utilize if it meets your requirements. Ted Pattison discussed this in an Office Space column a while back.
In regards to you other questions...
You can put a connection string in your web.config, we do this often. There can be concerns in SharePoint manually updating the web.config due to the fact you can have multiple servers in a farm and you don't want the web.config to get out of sync. SharePoint has a SPWebModificationClass you can to automatically update the web.config. I have run into issues with this using FBA (see this SO question).
You can use LINQtoSQL for your database access. However, if you are using SP 2007 instead of SP 2010, you will need to update your web.config to reference all of the proper DLLs. You can what references are required by looking at an ASP.NET 3.5 web.config and comparing it to SharePoints. I am sure there are links on how to do this also.
Hope that helps get you started
How do I change process template to MSF for Agile on an already existing team project in TFS 2010?
We have upgraded our TFS 2008 to 2010, and now I would also like to change the process template to MSF for Agile (currently CMMI).
We haven't used the workitem functionality much so if some information gets lost in the conversion doesn't matter.
Once you've created a Team Project, you unfortunately can't just upload a new process template. As Robaticus says, you'll have to download the XML for the template and modify it, then re-upload it. The power tool lets you create NEW templates for NEW team projects, but it won't modify an existing one.
Instead, you can use the witadmin.exe tool (on any computer with Team Explorer installed, under \Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, or just from a Visual Studio Command Prompt) to export the current workitem definitions and re-import them once you've made your changes.
Luckily, if you're not using workitem tracking much, then this might not be too difficult. You might be able to just delete all the existing workitem types and then re-upload the new types.
If this is too much trouble, consider how much you want to retain your source control history. It might be worth creating a new Team Project with the Agile template and then just moving all your source code into it.
You can't change the process template, however you can change the work item types. So for bugs, tasks you can swap to the Agile definitions.
You can do this in 2010 with witadmin, in 2008 it's importwit, by first downloading the template to disk (you'll need the TFS power tools for this). Then point the console app at bug.xml, task.xml etc..
Usage: witadmin importwitd /collection:collectionurl [/p:project] /f:filename [/e:encoding] [/v]
/collection Specifies the Team Foundation project collection. Use a fully specified URL such as
http://servername:8080/tfs/Collection0.
/p Specifies the team project in which the new work item type is imported. This is required, except when
the validation-only option is used.
/f Specifies the work item type XML definition file to import.
/e Specifies the name of the .NET Framework 2.0 encoding used to import the XML file. For example,
/e:utf-7 will use Unicode (UTF-7) encoding. Encoding is automatically detected whenever possible. If
the encoding cannot be detected, UTF-8 is used.
/v Validates the XML definitions for the work item type, link type, or global workflow without importing
them.
You can export the agile process template to disk, then import the work items into your existing project. You may need the TFS Power Tools to do this.
I may be too late for this question, but the TFS Integration Platform tools could really help here.
See this question on server fault that details on how to move from Scrum For Team System V2 to Microsoft Visual Studio Scrum 1.0.
You would need to setup your own mappings to move from your templates to the target template, but the process is the same.
Please note witadmin.exe could help in some scenarios but TFS Integration Platform is your ultimate choice to achieve this task. There is a user voice item still pending. Please check this SO thread.
I think the best way to accomplish this is to create a new Team Project with "the new" process template and use the TFS Integration tool to migrate your existing WorkItems and choose create a new branch from Source Control, so you'll have new work Items (with the new workflow) and the source control history (as well). You'd even do this across versions of TFS!! (On the case interested on migrate TFS 2005/2008/2010)
Another way might be to use the WorkItem Templates, but I think this is more a kind-of visual style (I've not much experience) applied to the Work Item. To do so, just right click on your project, import the WITDefinition and apply the template by selecting Apply template on desired WorkITems.