I want to develop an visual studio extension that does some automation for my sql database projects in visual studio. Among those task is adding the database references. I cannot find any way to do this from the extensions code.
I can get the proper project node retrieving ServiceProvider.GlobalProvider.GetService(typeof(DTE)) as EnvDTE80.DTE2;
and than iterating over the project in the solutions. But the project object seems to be of type Microsoft.VisualStudio.Data.Tools.Package.Project.IDatabaseProjectNode Which is marked internal and thus cannot be used by me.
Is there any official way to add database references (and do other sql database project specific things) or do I have to resort to editing the project files directly?
Sorry but the answer could be negative, after discussion with .net and SQL team, adding database reference is not supported for now.
Adding database reference is much more complex than adding normal reference(.dll), there exists no public API for this behavior in VS SDK.
Related
I am trying to setup an application and database in TFS 2017. For a standard windows application and SQL Database Project.
Should I combine the application project and the SQL Database Project into the same solution and Build together on TFS in the same Build Definition?
I a thinking these should be separate solutions in TFS and separate Build definitions in TFS. We can include multiple artifact references in TFS Release to deploy them both simultaneously.
Does this make sense?
Or does it make more sense to combine the solution and build definition into the same units of work?
Few questions to ask yourself:
Do the database changes need to go out with the code changes?
Probably combine them
Is the DB something maintained by another group that you just keep in sync? Maybe split them up
Is the database build adding a lot of time to your CI? Maybe split them up to improve performance, or cache the DacPac between builds
If they are in separate solutions, how are you planning to do code reviews or branching?
I've usually combined them, but have been thinking about something closer to the 3rd question to speed up builds.
A solution is a structure for organizing projects in Visual Studio. Whether combine the application project and the SQL Database Project into the same solution depends on your projects structure.
On TFS side, it's OK to use one build definition, as if you want to build only one project, you can specify the particular project.
As per best practice I have separated my BizTalk solution into projects based on artifacts (schema, pipelines, maps etc). I've also separated business processes into solution folders. I have created a common project to hold schema that need to be available for each and referenced these when needed... so far so good.
When I deploy it will deploy the common schema and each reference - resulting in multiple schemas. If I try to untick the dependency in the project assembly I get the error
This dependency was added by the project and cannot be removed.
Am I missing something?
Visual Studio 2012, BizTalk Server Dev Ed 2013.
Really, same answer as in the other post.
Consider the Visual Studio Solution as one Deployment Unit and build your processes around that. Meaning, all the Projects, Schemas, Maps, Orchestrations, would always go out together even if only one changed.
I try really hard to not share Schemas across Solutions specifically because of the Deployment issues. I do this even if it means duplicate or essentially duplicate Schemas. 99% of the time, the only thing that breaks is the automatic Schema resolution in the Xml Disassembler and that is easily solvable.
"When I deploy it will deploy the common schema and each reference - resulting in multiple schema"
Sorry, this part doesn't seem right. If you have a common Schema project, there shouldn't be duplicates.
Windows 8 store apps do not allow other projects within one's solution to perform CRUD operations even though these projects can have the proper reference to the SQLite DLL that's required.
As a result of my finding, I am duplicating my Data Access Layer code in all my Windows Store apps.
Thus, development time is increasing dramatically as a result of updating all my apps each time I need to account for recently added tables for the multi app solution that I am building.
NOTE:
I heard that implementing SkyDrive integration is an alternative approach that may solve this issue.
However, I made the decision early on to implement sync operations with SQLite and cannot afford to swap out data access layers at this stage of development.
Any suggestions?
Thanks,
Scott Nimrod
You can place your common data access code in a Windows Store Class Library (dll) project. Each of your applications can then reuse this dll.
Note that your shared dll project does not need a reference to the Sqlite3 binary dll (the sqlite3 Visual Studio extension). It should only be referencing the sqlite api (e.g. Sqlite-net). For your main app, the references should be reversed - it should reference the extension, but not the api.
I've been trying to figure out how to get a decent LINQ to something working for ORM database access in a Windows Store app.
All I've found is SQLite and the sqlite-net NuGet package. The latter sucks a bit, as I don't get any .dbml like structure which resolves relationships and provides navigation properties for easy querying (no manual joins needed then).
I was wondering:
Does dblinq in comnbination with SQLite offer this?
Will using this pass Windows Store validation?
Thank you !
Update: Some links I used in my research:
The famous Tim Heuer post on SQLite and Windows 8: http://timheuer.com/blog/archive/2012/08/07/updated-how-to-using-sqlite-from-windows-store-apps.aspx
DBlinq: http://code.google.com/p/dblinq2007/
sqlite-net: http://code.google.com/p/sqlite-net/
Interesting discussion stating ADO.NET is not possible: http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/e9cdd75d-03e4-4577-988e-4c02a52e3f50
I'm not familiar with dblinq but by looking at the sqlite tests in the project, it seems the library is offering what you're looking for, i.e. navigation properties for relationships between different tables.
Since dblinq is a .NET library, using it shouldn't make the store validation fail. There is another problem though: you can't use such a .NET library in a Windows Store application, only Windows Store class libraries and portable class libraries are allowed. Since the source for the library is available, you can try compiling it as a Windows Store class library, but I'm afraid there are going to be some classes missing that dblinq is depending on which might make it difficult to port.
Ok, so here's the thing.
I'm developing an existing (it started being an ASP classic app, so you can imagine :P) web application under ASP.NET 4.0 and SQLServer 2005. We are 4 developers using local instances of SQL Server 2005 Express, having the source-code and the Visual Studio database project
This webapp has several "universes" (that's how we call it). Every universe has its own database (currently on the same server) but they all share the same schema (tables, sprocs, etc) and the same source/site code.
So manually deploying is really annoying, because I have to deploy the source code and then run the sql scripts manually on each database. I know that manual deploying can cause problems, so I'm looking for a way of automating it.
We've recently created a Visual Studio Database Project to manage the schema and generate the diff-schema scripts with different targets.
I don't have idea how to put the pieces together
I would like to:
Have a way to make a "sync" deploy to a target server (thanksfully I have full RDC access to the servers so I can install things if required). With "sync" deploy I mean that I don't want to fully deploy the whole application, because it has lots of files and I just want to deploy those new or changed.
Generate diff-sql update scripts for every database target and combine it to just 1 script. For this I should have some list of the databases names somewhere.
Copy the site files and executing the generated sql script in an easy and automated way.
I've read about MSBuild, MS WebDeploy, NAnt, etc. But I don't really know where to start and I really want to get rid of this manual deploy.
If there is a better and easier way of doing it than what I enumerated, I'll be pleased to read your option.
I know this is not a very specific question but I've googled a lot about it and it seems I cannot figure out how to do it. I've never used any automation tool to deploy.
Any help will be really appreciated,
Thank you all,
Regards
Have you heard of the term Multi-Tenancy? It might be worth look that up to see if that applied to your "Multiverse" especially if one universe is never accessed by another...
See:
http://en.wikipedia.org/wiki/Multitenancy
http://msdn.microsoft.com/en-us/library/aa479086.aspx
UPDATE:
If the application and database is the same for each client (or Tenant) I believe there are applications that may help in providing the same code/db as an SaaS application? ie another application/configuration layer on top that can handle the deployments etc?
I think these are called Platform as a Service (PaaS) applications:
see: http://en.wikipedia.org/wiki/Platform_as_a_service
Multi-Tenancy in your case may be possible, depending on client security requirements, with a bit of work (or a lot of work):
Option 1:
You could use the one instance of the application, ie deploy the site once and connect to a different database for each client. You would need to differentiate each client by URL to isolate content/data byt setting a connection string for each etc. (This would reduce your site deployments to one deployment)
Option 2:
You could create both a single instance of the application and use a single database. You would need to add a "TenantID" to each table and adjust all your code to accept a TenantID to ensure data security/isolation. Again you wold need to detect/differentiate the Tenant based on the URL to set the TenantID for the session used for every database call. (This would reduce your site and database deployment to one of each)