I have two databases projects in a single solution, Database A and Database B. They both have queries that point to each other like this
Select * FROM [Database A].dbo.Table
Visual Studio will give you a warning like this SQL04151: Procedure xyz contains an unresolved reference to an object...... This warning is resolved in Database B if you add a database reference to Database A.
However, there are still warnings from Database A complaining about an unresolved reference to something in Database B.
If I try to add a reference to Database B from Database A it won't let me because it says 'A reference to library 'Database B' cannot be added. Adding this project as a reference would cause a circular dependency.
So I guess my question is how to I resolve the reference so that the warnings will stop be displayed?
In VS2010 DB Projects, you want to generate a *.DBSchema file for the referenced databases. Add that DBSchema file as a database reference inside the project. That will avoid trying to point to another project and creating a circular reference. You can generate the DBSchema files using VSDBCMD.exe with the "import" option to create the file from a database.
You may want to watch for errors on build. We had to build/deploy a database multiple times for a "new" build because of those circular references. The first time with drop/create for DB A, then create DB B, then update DB A. If we didn't, the objects depending on the other database wouldn't get created.
Related
I have a U-SQL DB Project (USQLdb) that defines a U-SQL database and it's constituent tables, procedues, etc. This project also references two assemblies for use in one of the stored procedures. The DLL files are held within a folder called assemblies within the U-SQL Data Root folder and are referenced within the database using the following script:
CREATE ASSEMBLY IF NOT EXISTS [Microsoft.Analytics.Samples.Formats]
FROM "/assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll";
This works when deploying to Local-machine or to Azure.
For testing purposes, I have added a U-SQL Application Project (USQLScripts) that references USQLdb, with U-SQL scripts that execute a stored procedure each with the aim of setting up Unit Testing.
When trying to run these scripts against Local-project: USQLdb however, database deployment fails. From the logs it is because the USQLdb deployment script cannot find the referenced assemblies in the Local-project data root folder:
*** Error : (204,6) 'Assembly file 'C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot\assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll' could not be read.'
I have specified the USQLScripts Test Data Source as the local U-SQL Data Root folder which copies all files found to the Local-project working directory here:
C:\<Solution Folder>\USQLScripts\bin\Debug\USQLScripts_altdata_5qktnwfj.gln\data'
though per the error message above, the USQLdb Assembly Reference is trying to find them here:
C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot
As the DataRoot folder is completely cleaned and recreated on each Local-project execution, how can I either get the assemblies into the DataRoot folder on execution or reference them approriately without changing the address in the U-SQL script included earlier, which works as required when deployed to Azure?
Turns out, that if I remove the U-SQL Database reference in USQLScripts, the files that are in the Test Data Source folder are now copied to the C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot folder, but the scripts cannot execute as the database they are trying to execute against hasn't been referenced. I get the impression that I am either missing something or have hit a bug/unintended behaviour...
Turns out I was missing something.
What I thought was an error in referencing the assemblies was actually an error in building the USQLdb project, that resulted in the assemblies not being available and a red herring of an error being thrown.
The culprit was the Target Framework Version of the assemblies being higher than both the USQLdb and USQLScripts projects. It appears this can only be changed by editing the .usqldbproj files manually in a text editor (specifically the <TargetFrameworkVersion> value), as there is no option within the Visual Studio UI to edit this project property that I can find.
Once I upped the Target Framework Version in the U-SQL projects to match those of the assemblies, everything now builds, deploys and executes as expected.
I've created a basic map in BizTalk. No connections have been made. My input schema is a file within the same solution but in a separate project. The output schema is from a referenced .dll file (it is a very big schema).
When I go to build my project file, VS hangs (isolated this to the newly created map). When I go to validate my newly created map it will hang on invoking component....
I have checked the Windows logs and looked for error dumps but no such luck, just a simple devenv.exe stopped interacting...
I can't find any reference to this issue. Does anyone have any ideas or have encountered this issue?
Thanks.
Update:
I have isolated the issue to the referenced .dll schema that I have within my project. If I replace the schema with another referenced or local schema it will work just fine. I do not have the ability to edit this particular referenced schema unfortunately.
I have seen this when a Default Value is set either in the Schema or Map anywhere in a recursive structure.
I have the situation where I'm working in a new database, built using a Visual Studio 2010 database project, which has a number of synonyms defined which point to our legacy database.
Our plan is to create views over these synonyms; the tables being referenced are horrible, so the views will mangle the data into a better format; after that we will use Entity Framework to provide an ORM for these views (the idea being that we can then swap the views for real tables as we migrate data).
Problem: I can script the synonyms in the database project with no problems. However, when I try to create a view which references these synonyms, I am confronted with an error similar to:
Error 1 SQL03006: View: [dbo].[Person] has an unresolved reference to object [dbo].[ma_contact].
...where [dbo].[Person] is the new view and [dbo].[ma_contact] is the synonym for the legacy table.
Workaround: Place all view creation scripts in Script.PostDeployment.sql, doing the if-exists-then-drop-then-create logic manually.
This is less than ideal, although it's livable-with for now. Anyone have any ideas as to how to do these views "properly"?
Have you tried adding a database reference to your original database? You'd have to extract its format into either a dacpac (for SSDT SQL Projects) or a DBSchema file (for DB Projects). Once you've done that, store it in some place the project can find it. We used a "Schemas" folder at the root of our DB Projects so all projects could reference it. In your project, right click the "References" folder and add a Database Reference. Search for your DBSchema/Dacpac file and use that, along with the name of the database. That should let your synonym resolve properly so you can reference it in your views.
I have the following project structure using a Domain Model, StructureMap and Fluent NHibernate:
The problem I'm having is that Fluent NHibernate requires all of the following to be the bin directory of the website for it to work at runtime:
Antlr3.Runtime.dll *
Castle.Core.dll
Castle.DynamicProxy2.dll
FluentNHibernate.dll *
Iesi.Collections.dll *
log4net.dll *
NHibernate.ByteCode.Castle.dll
NHibernate.dll *
The problem I'm having is that not all of these assemblies are output to my website's bin directory. Currently only the items with a * are output correctly. The items in bold are missing from the bin directory.
Now, I would of assumed that the reason for this is because I have not added them as references to my Fluent NHibernate project. The only references I currently have are to NHibernate.dll and FluentNHibernate.dll. These two references alone are enough to bring through the items marked with a *, but they do not bring through the missing items.
So, I then thought that to get them to all come through I'd just add them as references to the Fluent NHibernate project. Unfortunately, this made no difference; the same items were still missing from the bin directory.
I've never really understood how visual studios decides which assemblies to copy over. I always assumed it was any assembly marked as Copy Local=true, but this doesn't seem to be the case in this scenario.
Of course I could just add all the assembly references into Website, but then that'd completed defeat the point of loosely coupling the projects through StructureMap.
Does anyone have any idea why the assemblies are missing and how I can get them to copy over correctly?
You can either add references to the project that requires those files be present in the output directory (Website in your case) or you can add a post-build step in your build script to copy them across.
This is a case of VS and the compiler being "smart" about whether references are actually required or not. The C# compiler optimizes out those references that aren't actually required. Adding a reference to non-required assembly in VS will ensure it appears in the output directory of that project. However, dependent projects will only get that same assembly if it's actually used by the project referencing it. That is, if the C# compiler hasn't optimized its reference out. That's why you would need to add the reference to the Website project, if you go that route.
Personally, I did exactly that. I don't really think this is tight coupling since NH still resolves the assemblies dynamically at runtime. And it's not like I can't just substitute in other byte code assemblies manually and restart my app. But it's also not like I would do that without adequate testing, so in a way I consider myself to be coupled to Castle on the basis of that. And, therefore, I'm not irked by the references.
Duplicate - this exact question was asked here - the only solution seems to be post build event.
In Visual studio 2008, I have the following projects:
A - references B
B - references Lib.dll
When B is built, Lib.dll appears in B/bin/Debug. (this is ok)
When A is built, B.dll appears in A/bin/Debug, but Lib.dll does NOT appear in A/bin/Debug.
Wouldn't it be logical behavior to copy also all B's dependencies to output path of A, since B will need these assemblies at run-time?
All references have copylocal = true.
(Now I have to reference all B's dependencies from A by hand, is that correct? I could also use a custom build step I guess. Anyway, does this behavior have any advantages/sense?)
This only works if the assembly is actually referenced by the .dll. i.e. If you have LibInterface.dll and LibImplementation.dll - and your code in A only references the classes in LibInterface.dll, there is no way to get LibImplentation.dll into the output for B (cleanly).
This also applies for any arbitary files - i.e. if you have Randon.myFile that is related to project A, this would be the desired procedure:
1. Add as copy local, or build event to project A (so turns up in output for project A)
2. In Project B, set "copy local" on project A ref.
3. You should then get everything in the output of project A in project B (including your file) - but you don't.
There could be some other option - "Copy Local - all" or something. This would help VS support IOC techniques, and clean abstractions.
If Lib.dll is an interop dll then its underlying dll won't be copied. Other than that I'd say there's probably operator error because you definitely don't need to manually reference dependent managed assemblies.
I have done the same procedure many times and it is not necessary to re reference assemblies manually. One easy way to test this is:
reference B in A
Create an instance of an object from B in A.
Compile.
If the build completes successfully, everything is referenced OK.