I have a very simple SQL Project in Visual Studio 2013 but cannot publish to another database.
Within the obj folder it generates the "MYPROJECT.generated.sql" file, but the Microsoft.SqlServer.Server attributes are outputted above the CREATE ASSEMBLY.
CREATE PROCEDURE ....
AS EXTERNAL NAME [MyProject].[StoredProcedures].[MyMethod]
GO
CREATE TRIGGER ....
FOR INSERT
AS EXTERNAL NAME [MyProject].[Triggers].[MyTrigger]
GO
CREATE ASSEMBLY [MyProject] AUTHORIZATION [dbo]
FROM 0x234234...... (DLL as Binary Hex)
WITH PERMISSION_SET = SAFE
My problem is that this generates an error because the [MyProject] was not found in the SQL catalog. If I manually move the CREATE ASSEMBLY to the top then it works as desired.
I assume a T4 template is generating this file and was wondering if anyone knows how to update/swap the template so that I can shuffle the order (and perhaps add schema to the SqlProcedureAttribute)
[UPDATE]
My target database takes 30min to publish and I need a faster turn around for developing/debugging SQLCLR projects. My SQLCLR is a separate project that is set as a dependency from my large target database (build order). In the interim I've created a vbScript that is invoked in the SQLCLR post build event to copy the SQLCLR/prebuild.sql and combine the bottom of generated.sql + top of generated.sql + SQLCLR/postbuild.sql into a consolidated Target/PostBuild.sql. These two scripts are fired from the pre and post build scripts of the target database. This ensures that my assembly hex is current and targets the proper configuration (DEBUG|RELEASE) and I can manually deploy it outside of the target project. (3 seconds vs 30 minutes to redeploy my assembly)
[UPDATE2]
I'm modified it from generating a scripts to attach to the main project, to a standalone project with linked files. This way the large database project deployment remains unchanged and deployed with dacpac, and I have a separate project that I can use for fast build and deploy testing
Related
I have a sql database project in visual studio 2015, that includes a clr stored procedure that calls a webservice. I have configured the projects to auto generate the serialization assembly. This means in de output folder I get both a projectname.dll and a projectname.XmlSerializers.dll.
I use the visual studio schema compare function and that works fine in comparing and updating projectname.dll but it does not show projectname.XmlSerializers.dll which I have to update by hand every time.
How do I get the schema compare to recognize and update the projectname.XmlSerializers.dll file?
In order to get SSDT to load a DLL that is not being created directly from your project into SQL Server, you need to do the following two steps:
Add the DLL to the Project (Add Existing Item)
For the properties of the newly included DLL, make sure that "Model Aware" is set to "true".
We're using Code First in EF6.1 - our model is over 300+ tables now and startup time is ridiculous. We've tried pregenerating views already but it didn't help much, it's the model compilation in the Code First pipeline that takes most of the time.
We're going to try using the Database / Model First approach for initializing the context by using an entity connection string with metadata links to CSDL, SSDL and MDL files, instead of a direct SQL connection. This would be our ideal process:
After the project containing the Code First model is compiled, a post-build task runs that generates an EDMX file from our DbContext, splits it into component CSDL, SSDL and MDL files, and embeds these files in the assembly as resources
When we create a context via our own factory, we wrap the original SQL connection string in an EntityConnectionStringBuilder, with the Metadata property pointing to the embedded resources, and use the builders connection string to initialize the DbContext
Initial testing shows an ~80% improvement in startup time - the tricky part here is doing the post-build resource embedding in step 1!
Can anyone provide any clues as to how step 1 could be done in MSBuild? Is there an alternative strategy that would work as well? Basically we want a zero-maintenance solution so that developers don't have to manually do anything other than build their code, with no special deployment considerations either.
EDIT:
We ended up using a new, separate class library project that references the project containing the Code First model. This project contains a T4 template that writes the EDMX from the DbContext into memory, then saves the component parts into project files that are already marked as embedded resources, so we get source control as well.
The build order guarantees that the resources will always be up to date, and the entity connection string references this resources assembly at runtime. The MSBuild integration was done by using the T4 MSBuild integration targets so that the template always runs during a build of the project.
You should certainly be able to do this with MSBuild. You will have to pick up a little bit of build script, but shouldn't be too bad.
How are you doing it now? Do you have a console application that you run to generate the edmx? It sounds like you have already done the hard part -- integrating with MSBuild should be easy. I will assume that you do, and go from there.
btw: One thing to know up front is that you .csproj files are MSBuild scripts, so any custom MSBuild scripting can go into those csproj files.
In order of increasing complexity, you could:
Add an "After build" event to your project that executes your console app. This option does not require any MSBuild script -- you just set up an after build event in the project options. It will always run, though. (I don't think you can make a post-build event dependent on configuration), so it could slow down your compile times.
You could use the Exec task in MSBuild to execute your console application. This will require a little editing of your csproj file, but you can make it conditional if you need to. Here's a link to the Exec task: http://msdn.microsoft.com/en-us/library/x8zx72cd.aspx If you put it in a target named "AfterBuild", it will automatically execute after your build has completed.
You could write your own build task -- this is a c# class that will be loaded and executed during build. This is the most sophisticated way to do it, but it also gives you the most control: http://blogs.msdn.com/b/msbuild/archive/2006/01/21/515834.aspx
One of the nice things about the last option (custom build tasks), is that you can write error messages back into the build process. That should help with getting helpful information if the task fails, and if you use a build server, those messages should be picked up by the server in the same manner as any other build message.
I have a Visual Studio 2010 solution with many projects and many build configurations in order to make use of Web.config transformations for automatic deployments.
My problem is when a new project is added it does not inherit the existing configurations and thus the build fails on the build server.
As an example, say I have the following custom build configurations:
Development
QA
Production
When a new project is added, it only contains the standard Debug and Release configurations and none of the above custom configs.
The only way I know how to fix it is to manually edit the .csproj file.
What is the proper way to handle this?
Edit I have removed the information about why it fails on the build server because that is irrelevant (and obvious), I just need to know if there is a way to have existing custom build configurations automatically picked up by a new project being added to the solution.
The proper way to handle something you have to do manually on a computer is, usually, doing it automatically. No kidding. All our project files (both C# and C++) are generated: they automatically import the correct property sheets with all build options and all have the same platforms/configurations. It's a relative small amount of work to throw together a program that will save you much more time and effort later on. Basically the Microsoft.Build.Construction namespace has everything you need. To make the program user-friendly we added a small ui on top that lets you drag in directories in which to create projects. So we just run it, create a directory, drag it onto it and add the new project to the solution in VS.
I have a solution in visual studio where one project (.csproj) is set to create an exe.
I would need to create a duplicate copy of this project so that I can name it something different and change the icon for it. (All of the rest of the projects can stay the same)
I am using conditional compilation symbols for that project, but I don't want to create a whole separate solution configuration because that requires expensive rebuilding of the entire solution.
In Visual Studio under Build -> Configuration Manager, you can create a new configuration for your project and clone it from your release build, then in your project properties you can customize it.
For the icon, you'll want to refer to Set a different ApplicationIcon for each build configuration
Create a copy of the project on disk (outside Visual Studio) and add the copied project to the solution. Then you can modify output assembly name, icon. etc..
However better practice would be to perform the necessary operations as postbuild step (e.g. batch/powershell script) as you will have to keep the projects synchronized (added/renamed/removed files, references...)
Copy it somewhere else and change the assembly name and namespace may be on the project property window( right click and property)
I dont know what your trying to accompish but possible solutions:
add post build event that will copy exe / (exe ad dll-s) to another directory
if you use TFS, edit your Build so it will create copys
Cheerz,
We have a C# desktop application which we run for clients on various servers on a software as a service model. We are still on dot net framework 2.
The software has a architecture in which we have an independent application to catch external data thrown by some server. Then an application to make calculations based on it. Also one more application on which the client sees the output. The link between the 3 applications is another application which communicates with the DB.
The 4 solutions are on a SVN for sourcecontrol. But the release management is still manual and the patches are made manually by checking the log and including the dlls, pdbs, xml. etc for the projects for which the code has changed.
There is no assembly versioning implemented and the patch or release management is just done in the dark.
I want to know what is the industry practice for generating automatic patches from the code. Also I want a patch for each revision in the SVN. Also is assembly versioning helpful in this?
I have read much about continuous integration but it fails because we do not have unit tests and other fancy code to moniter the correctness of code.
The only thing at this time I would be interested is to implement a way to make patches which can be applied and removed easily. Also I want to know a way to determine the way we can monitor which release is at which level(or what patches have been applied) by some automated way rather than maintaining a log manually.
We use a build script which creates a SvnVersion.cs file containing the last commited revision. This file is placed in the root of the solution, and then added to all projects in the solution (but added as a link, not copied).
The template for the file (SvnVersion.Template.cs) looks like this:
using System.Reflection;
[assembly: AssemblyVersion("1.0.0.$WCREV$")]
[assembly: AssemblyFileVersion("1.0.0.$WCREV$")]
And we simply use TortoiseSVN to fill these placeholders in a batch script:
type "%TRUNKPATH%SvnVersion.Template.cs" > "%TRUNKPATH%\SvnVersion.tmp"
SubWcRev "%TRUNKPATH%\" "%TRUNKPATH%SvnVersion.tmp" "%TRUNKPATH%SvnVersion.cs" -f
IF ERRORLEVEL 1 GOTO ERROR
DEL "%TRUNKPATH%SvnVersion.tmp"
If you don't use TortoiseSVN, there are other ways to get this info in the file.
You will also need to remove this same information from your AssemblyInfo.cs files or you'll get a compile error. Also, to speed up Debug builds, this is only executed in Release builds (and in Debug builds only if the file doesn't initially exists, like after a fresh checkout).