I have a VS2012 database project which includes tables, stored procs, views etc.
I then have a second database project which contains a database reference to the first project. I have ensured that the "Include composite objects" options is selected from the "Project Properties -> Debug -> Advanced" menu.
When I build the second project and take the resulting DACPAC file and deploy it through SSMS2012 it doesn't create the firsts project's objects.
Am I missing something? Why don't the composite objects get included in the DACPAC?
As Peter Schott said in the comments above, I needed to deploy both outputted Dacpacs in order, with the referenced database first.
You cannot do this through SSMS, it won't allow you to deploy two different Dacpacs to the same database. But it is not a problem through SQLPackage.
I had the same problem when publishing dacpac with dacfx. As answered here, I had to activate the "Include composite objects" option. But that's not all. When you compile your project, Visual Studio generates two dacpac files in your "second" project. You must put both files in the same directory when you deploy the second project.
Hope that helps, for me it did ;-)
Related
In a biztalk project, why do some XSD files have a hidden xsd.cs and some do not? What are these files used for and why is it, modifying the XSD and rebuilding does nothing to modify the .cs files?
For example: I have an XSD which is used to map messages to a SQL Send/Receive Port and execute a stored procedure. If I change the stored procedure (say change, delete, add a parameter) and thus, change the xsd to match, these changes aren't reflected when I deploy the orchestration unless I delete the xsd.cs. I CAN see the modified xsd in the Schemas tab of the BizTalk Administrative Console. I can see it is modified, yet I will still receive a message routing / mapping error unless that .cs is deleted and the orchestration redeployed. And by the way, after deleting, it never seems to regenerate though it also does not cause any issues.
Every xsd in your solution should have a .cs file. If you aren't getting them then there is something wrong with your solution. They are the compiled version of the schema that get deployed to the GAC. If the .cs file is not being changed after you recompile then you again have an issue. Check to see if you've accidentally checked the .cs files into source control and that they are now read-only (they should not be checked in).
When you modify the schema you need to both update the version of the schema in the BizTalk database and in the GAC. If you don't you will get some strange results. Using the Deploy option from Visual Studio will do this for you automatically, but if you are manually deploying you will have to ensure that it is both imported and GACed.
.cs files are generated for every BizTalk Artifact, that's how them become a .Net Type.
All of this should be handled automatically by Visual Studio. If you are having problems that only deleting .cs files will solve, then there's something wrong with your VS setup.
Note, the .cs files should not be in source control. If they are, remove them.
However, the scenario you describe doesn't make sense. What you see in BT admin is from the .cs file.
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
I'm following the tutorial here.
I created a new Web Application. I then added two Class Library projects, Common and Domain. The common project contains the SubSonic library while the Domain project contains the SubSonic .tt and .ttinclude files.
After modifying the settings in Settings.ttinclude, I try to 'Run custom tool' on the tt files and I get this error:
Running transformation: System.ArgumentNullException: Value cannot be null.
Parameter name: The project does not contain App.config or Web.config file.
I can provide the rest of the stack trace, but it appears that it can't find my Web.config which was the connection string. Adding an app.config to the Domain project just causes the generation step to complain about not finding expected sections.
Is there a way to have these files in a separate assembly but still use the web.config for settings?
You need to place an App.config in the project you want to generate from. Yes, it's redundant but there's no other way to handle this with T4
I would like to add basic logging and make some other minor changes to the classes generated by SubSonic 2.1 (I'm not using SubSonic 3.0 t4 templates).
Is there a way to do this without modifying the SubSonic source code?
You have two choices. You can modify the default templates or create your own. I suggest making your own templates which will lives side-by-side with the original and then generate your code via the following instructions.
Note that these steps assume you ran the default SubSonic installation. In other words, Sonic.exe and the default templates can be found under c://program files/. If not, you'll find your SubSonic files/templates in an alternative installation location, of course.
Make a copy of the default templates folder as found in C:\Program Files\SubSonic\SubSonic 2.1 Final\src\SubSonic\CodeGeneration\Templates. I might recommend naming the copied folder "TemplatesWithLogging.”
Open the aspx files in Visual Studio and modify to your heart’s content. For example, I wanted an alternate C# class template so I modified CS_ClassTemplate.aspx. If you want to merely alter the default templates, you can but I suggest making a backup first.
I am going to assume you are already familiar with code generation with SubSonic. I personally like to setup a Visual Studio External Tool to allow for quick, pre-configured regeneration. Otherwise, the following can be ported over to the command line. Here’s the External Tool setup instructions:
Tools > External Tools > Add Title: TemplatesWithLogging
SubSonic Classes Command: C:\Program Files\SubSonic\SubSonic 2.1 Final\SubCommander\sonic.exe Arguments: generate /out Generated /namespace NAMESPACE /server SERVER/db DATABASE where NAMESPACE, SERVER and DATABASE are replaced accordingly.
Initial Directory: $(ProjectDir)
Check “Use Output window” and “Prompt for arguments.”
Select Apply or OK
4.Select the project which will contain the “Generated” folder and auto-generated files. Select Tool > TemplatesWithLogging.
You can find more here.
Yes you can modify the templates that version 2 uses, they're just aspx files. The templates are stored in src\SubSonic\CodeGeneration\Templates under your installation directory.
This blog post goes into more detail:
http://johnnycoder.com/blog/2008/06/09/custom-templates-with-subsonic/
I am working on a sharepoint feature which includes a couple of list definitions, 2 webparts, a feature receiver assembly and an InfoPath form.
I have to use WSPBuilder to package these, and the requirement is to package all these features into a single WSP solution file.
Now, WSP builder requires the deployment files in a particular folder structure, same as the 12 Hive of sharepoint.
My problem is that all my features were developed separately, and consist of multiple project files, and these are not necessarily in the same folder structure..
How do I use WSP Builder to package multiple features into a single WSP solution?
Maybe this will help: http://www.codeplex.com/wspbuilder/Thread/View.aspx?ThreadId=43125
Ultimately, I think you gain a lot of flexibility by building your own wsp files by using a tool like NANT.
There's no particular action you need to undertake in wspbuilder to have multiple features in the same solution package.
All you need to do is create a new folder for each feature under the 12\TEMPLATE\FEATURES folder inside your solution in Visual Studio and place the appropriate feature.xml file in that folder. For example, you may have:
12\TEMPLATE\FEATURES\FancyFeature\feature.xml
12\TEMPLATE\FEATURES\ReallyCoolFeature\feature.xml
... and so on.
Upon building the solution, wspbuilder will read the entire tree structure of your 12 folder and append the corresponding nodes in the wsp's manifest.xml file. The same goes for any other possible subfolders inside the "TEMPLATE" folder, including IMAGES, LAYOUTS, etc: at deployment time they will all be copied in the correct folder inside the real 12 hive, because the 12 folder inside your solution is meant to be a replica of the original one.
For a better understanding, create some folders and files inside your 12 folder in the visual studio solution, compile your project and look inside the generated manifest.xml file.
The simple answer is that you are going to have to copy all the files form the individual projects into one master project for your solution. As long as all your individual feature files are in the correct location in your '12' folder then you'll be good to go.
Note: You'll need to check all your references to any assemblies as this solution will create 1 assembly for all your custom logic.
I had trouble adding dlls to the wsp so I wrote a short article about it: How to Add DLLs to a WSP Solution
I usually have one project in the solution designated as the "main" one. I set the dependencies so that this "main" project is built last. Then for the other projects that I want to be included in the wsp package, I edit the "Post Build Events" to xcopy the contents of the 12 folder and that dlls built by the projects into corresponding folders for the main project. Then after I build the whole solution, I can build the wsp package for the main project and know that it contains everything.