In visual studio 2012, I create new report server projects using the default template below:
When the project is created, it specifies the following build/deployment settings in the configuration:
Obviously these settings are not appropriate for my environment, so I find myself changing them manually every time I create a new report server project.
Is there any way I can change these settings in the default project template so that they will be automatically populated whenever I create a new report?
EDIT: I tried what Reed suggested, but the option was greyed out. Does this indicate that BI projects don't support default templates? If not, how can I create a new custom template for a report server project?
You should be able to create a custom project template for VS 2012 with these defaults modified.
It depends on your environment and your workflow. The below is my personal preference and is a potential solution to your issue:
I tend to use a single report project solution for all my SSRS development, but only for the reports being worked on at that time. It contains all the shared datasets I use for live and test environments and all other settings are as I need.
When ready for deployment, I move the rdl into source control and deploy from there, deleteing the rdl from the project in the process. This helps to keep syncronisation between live reports, source control and filesystem.
In my experience, its far too easy for someone to accidentally modify and deploy an older version of a report from a shared directory.
It will enable you to have the settings you need when you create a new report, as you will not be creating another solution.
Related
I have a "common" web template project in tfs. This web project is mainly for common layout and library framework that will be used for many other projects.
Every time I work on a new project, I always create a branch from the "common" template. With such structure, if there's new changes on the common framework, I can always merge the new changes to the "common" template.
The problem I face now is when I have multiple projects open and I try to run the project, it always run the project I first opened in VS. It think this could be due to the assemblyinfo.cs in the project. I tried to change the solution name and the project name but couldn't resolve the issue.
My VS version is 2012 Professional
I still couldn't find a suitable answer for this. What I had to do to get around is to set the virtual port on the web project.
We've recently upgraded to Visual Studio 2013 and we're having some issues with the new way publishing is handled. Previously, (in VS 2010) every user had their own local publishing settings, but in VS 2013 it's changed to the idea of shared publish settings. This is causing problems with our environment because every developer has a different local dev environment (paths, connection strings, email addresses to send things to). I realize this is not the optimal way to have things set up, but that's the reality of our situation right now.
We use config transforms to handle the various web.config changes for different developers, so just running through VS doesn't work for us because it doesn't run the transforms. This also causes a problem with the VS 2013 publish settings because the last build config used is stored in the shared publish settings. In order to keep all our settings different, it looks like we're going to need to have a different publish setting for each developer now as well (such as "Local - Erik", "Local - OtherDev"). This is just going further down a path I'd like to get out of eventually.
So my question boils down to: Is it possible to somehow disable the shared profile settings? I thought of just not including them in version control, but then Visual Studio complains that the files are missing on other developers' systems.
Thanks for the help!
You can do this by excluding the profile from the project after you create it. The publish wizard looks for any profile on disk, but newly created ones are added to the project by default. If you then exclude the .pubxml file from the project and remove it from source control, it shouldn't bother you again.
I'm trying to define a new build on TFS using VS2012. When I go to New Build Definition -> Processes I'm seeing "Build process template" and an empty drop down.
I click on the "New..." button selects the default template from
$/<My Project Name>/BuildProcessTemplates/DefaultTemplate.11.1.xaml
and click OK but then I'm getting the error:
TF277000: A build process template for '$/<My Project Name>/BuildProcessTemplates/DefaultTemplate.11.1.xaml' already exists for team project <Project Name>. You cannot create another build process template for the same file. Use the existing one instead.
the drop down always stay empty. I tried to clean cache(AppData\Local\Microsoft\Team Foundation\4.0) and other sort brilliant tricks like close and open but nothing helped - the drop down stays empty.
I would really appreciate aמy help.
I had a similar issue crop up recently.
Background: TFS 2012 Project with multiple solutions under 1 Project Collection project. The 'BuildProcessTemplates' folder did exist in the Project collection project and did contain the standard templates. The solution was created in TFS 2012 and being coded using VS 2012 ultimate.
Symptoms: Any attempts to create a Build Definition failed due to a lack of Templates.
Actions - unsuccessful: I created a copy of the default template and used that for a template. I wasn't able to create a Build Definition since even with that, the dropdown was still empty. Also tried creating a custom template with the same lack of success.
Actions - successful: I separated the solutions into their own Project Collections projects. That put the solution at the same level as the 'BuildProcessTemplates' folder. Once that was accomplished, I was able to create a Build Definition for those solutions.
Comments: I'm not sure if this is a bug in TFS 2012 or not. I would like to think if it is a bug in TFS 2012, it is corrected in TFS 2013.
Your thoughts?
Robert
I recently ran into the same problem with not being able to see build process templates when trying to add a new build definition. We are in TFS 2012. This team project also appeared not to have any build definitions. That was expected though because we had not yet used the TFS builds on this team project.
The problem was caused by someone with admin rights setting the "View build definition" and the "View Builds" access rights to Deny for everyone.
By just setting that back to allow on the TFS group, we suddenly could see the build definitions and also were able to select build process templates.
It was really strange that it let us add new build process templates, but we couldn't select them.
I have a website project that is consuming user controls from another shared project. I am using a build event to copy the *.ascx files over from the source user control project.
I don't want the ascx files to be checked into TFS source control from the consuming project, only the source project. Is there a way to keep TFS from trying to check in files from a specific folder other then cloaking?
My issue with cloaking is that it's a client side function, which means every developer who takes down the project would have to manually cloak the folder or folders in question themselves. I'd like to be able to setup the solution in such a way as a developer could take the project down from source control without having to manually configure it to accommodate my separate project for shared user controls.
There is an article here: http://devio.wordpress.com/2009/11/05/shared-aspx-and-ascx-files-in-visual-studio-and-tfs/ that seems to address this issue but I think they're setup is different then mine in that I am using a website project and not a web application project. Being that I have no .csproj file there's no way to include or exclude files from my project.
Check out the TFS Power Tools (if you haven't already) http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f, under Team Members > General Settings, you can setup a Worspace Template to cloak as needed.
Not played with it myself, but looks to be the functionality that you need.
Can anyone shed some light on how to get Team Build 2010 beta 2 to push a SQL database project to the SQL server?
In VSTS 2008 you'd just add MSBuild commands with the targets attribute set to "deploy" in the TFSBuild.proj file, but I'm having a little trouble translating that to the new workflow based xaml thing that 2010 uses.
What I'm looking for is how to trigger the actual deployment of the databases themselves. It is already generating the deployment scripts just fine.
For anyone still looking for the answer, use an Invoke Process that uses vsdbcmd.exe:
http://msdn.microsoft.com/en-us/library/ff805001.aspx
Here is an example:
http://www.nablasoft.com/alkampfer/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
It may be that you are simply missing the DeployToDatabase=true
There is another solution to this problem if you don't need incremental database upgrade. So if recreating the database for each build is ok with you the following would also work.
Add a deploy target to Database Project file
Configure the deployment settings for ‘My project settings’. Those settings will then be used by the build server when building the solution. When building locally, the settings used will be the ones from ‘My isolated development environment’.
In the database project properties
Deploy Action needs to be ‘Create a deployment script (.sql) and deploy the database’; this will prevent the execution of the script, it will only create it.
Database project file
Modify the database project file (right-click database project, select Unload, right-click again, select Edit [ProjectName].dbproj)
from
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
To
<Project DefaultTargets="Build;Deploy" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
When the Build server builds the solution containing the database project, adding the default targets will also deploy the database. This build will use the Deploy settings selected for ‘My project settings’.
Pros
Easy to set up
Cons
Because the default target is changed to Build and Deploy, when a developer do a local Rebuild of the solution, it will also deploy the database (building only won't trigger the deployment)
The closest thing I've found so far is this post from Jim Lamb (the Team Foundation PM at Microsoft).
Here he talks vaguely about creating a custom proj file and modifying the default build process template to invoke the proj file.
He also talks about using the upgrade template, which I'd previously ignored. Apparently the upgrade template can be used to invoke a 2008 build definition. I'd rather not invoke and define the entire build based on the legacy proj file though, but at least it is an option.
Neither topic contains sufficient information for me to actually make the modifications necessary, but it does give me a reasonable starting point for some future experimentation.