I am having problems with a build server that I am trying to set up.
We use telerik, and have installed the libraries with the telerik control panel. The build process searches for the dll's all the wrong places.
Needless to say that the solutions builds perfectly on developer maschines.
The solution contains many projects, and not a single main project. I really do not want to have to change all the proj-files.
What I want is to add the telerik directory to AssemblySearchPaths, but using the msbuild parameters from the gui only got me to overwrite the AssemblySearchPath - with the result that the location of everything else but telerik files became unknown to build.
So I located a .targets file, which I read in the logfiles were utilized by build to set AssemblySearchPaths. And adding the telerik directory here did the trick (alas I still cannot get the build server to find the nuget dll's but that is another story).
However, I see that depending on selected CPU and perhaps other circumstances, the build uses another similar named .targets file from another location. Also, I find it less than optimal that such crutial customization is hidden away in a automatically installed file somewhere obscure.
So the question is: how to add more searchpaths to the ones already defined by the framework?
I am somewhat unfamiliar with ms build, but I did see an full fledged ms build file once which is why I knew it defines the build searh paths. However; alternatives which does not require that I change the projects in the solution will work for me.
Thanks!
Firstly, you need to be clear that: when you queue a build in VSO, the queued build is running on the Hosted Build Server. However, the software environment is different than developer machines, that is the reason why you can build successfully on developer machine but not on hosted build server.
If you would like, one easier way to resolve your issue is to set up the developer machine as the build server. You can register that developer machine with VSO, then all builds will run directly on the developer machine. Check this MSDN article for the details on how to set up build controller: https://msdn.microsoft.com/library/ee330987.aspx
If you don't like to set up the on-premise build server for VSO, you need to use Nuget restore function to resolve the assembly reference issue, because as far as I can tell configuring AssemblySearchPaths is not so convenient. Please check link for the details on how to have NuGet packages restored during the VSO (TFS) build process: http://docs.nuget.org/consume/package-restore/team-build
Related
I'm having the following 2 errors when trying to build on the build server:
path\to.NETFramework\Microsoft.Common.targets (3390): Could not copy "path\to\xxx.dll" to "path\to\yyy.dll". Exceeded retry count of 10. Failed.
and
path\to.NETFramework\Microsoft.Common.targets (3390): Unable to copy file "path\to\xxx.dll" to "path\to\yyy.dll".
The process cannot access the file 'path\to\yyy.dll' because it is being used by another process.
Locally, it's easy to fix - closing Visual Studio and running it as admin solves the problem. However, when using the build server (Microsoft Server), I can't seem to fix the problem.
Already tried restarting the build agent.
Made sure my project was the only one building at the time.
Manually deleted the dll.
Run the agent with the /m:1 argument.
Thanks.
EDIT: I've managed to reproduce the error locally. If I change the configurations in the configuration manager and clean->rebuild the project, it gives me the same error. However, like I said before, restarting VS solves this error, I just don't know how to do it in the server.
If you are using XAML build you could try to solve this problem via a setting of disable the parallel build in the build server.For TFS2010 and TFS2012 setting MSBuild Multi-Proc on the Process tab to False, for TFS2013, TFS2015 type the /m:1 in MSBuild Arguments. For more information about the /m argument in MSBuild, please refer to this document: MSBuild Command-Line Reference
Switching to single process builds has increased the build time, but if it's an acceptable loss. You could use this as a workaround.
Finally managed to find the solution. Turns out it had nothing to do with TFS itself. I wasn't able to reproduce the error locally because, for some reason, it was compiling when it shouldn't.
My problem was "broken references".
I am using some Biztalk programs and 5 of them had a dependency to other project (custom Biztalk Pipeline Components), but not the reference to the project itself. I think this maybe was caused by opening the components toolbox, although I'm not sure of it.
So, I manually removed and added again the references (Add->Reference) to said projects and now everything works like a charm.
I'm trying to figure out how to publish an application I wrote. We didn't get to publishing in class, and my programming teacher is having some health issues and isn't available right now.
I found the "Publish" option, and can get it to create a folder with an install program... but I open it, and it just opens the program, and spams me infinitely, complaining that my Access database (located in the bin > debug in the build stage) can't be accessed (from some weird path I don't recognize). I tried using WiX, but it gave me an error when I tried to install, saying it doesn't have access to the install folder (running as admin). I've been googling for a few hours, poking at it, exploring, and I'm not getting too far. Can anyone ELI5?
When you use the "publish" option for desktop apps, VS creates a click-once installer that will place all the files it knows about in the appropriate locations.
Unfortunately, it can't guess which other files your application needs so you need to tell it explicitly.
If you right-click the Project->Properties, go to the Publish tab and click the "Application Files" button, you'll see all files that will be added to the installer.
Next, click "Show all files" at the bottom. Find your database, and change the Publish Status to "Data File".
Note that I've only ever used the Click Once installer to install static files (like images/documentation) that are never modified, only replaced in later releases. I'm not sure whether your (modified) db will be preserved during an update but I suspect not.
If the Click Once install process is too simple for your needs, VS2010 has "Setup Projects" which create more complex installers that support logic/code. For VS2012, the commonly suggested option is Wix. Unfortunately, it's got a steep learning curve but it can do pretty much anything you need.
I believe VS2013 and later have setup projects again through an extension but I haven't tried it myself.
Edit:
The easiest way around this is likely to set the connection string programatically based on where the application is executing from.
Note that as per this answer clickonce apps are usually executed from deep inside the user profile directory (also read the answer below about data directories). It's a side-effect of how ClickOnce works (it wants to install somewhere the user is guaranteed to have write access).
Check if there really is an .mdb in that folder. If not, you need to tweak the installer or the properties for the .mdb. Assuming it's in the same location as the executable, you can tell your application where to find it...
string dbPath = IO.Path.Combine(
AppDomain.CurrentDomain.BaseDirectory,
"access.mdb");
string connectionString = String.Format(
"Provider=Microsoft.Jet.OLEDB.4.0; Data Source={0}",
dbPath);
I'm not sure why you think the database file added by the installer is in a directory directly under C:\. It's possible you're not looking at the file created by the installer.
To avoid confusion, try changing the name from access.mdb to something else (temp.mdb?), build the installer, rename back to access.mdb. Now, when you've installed the application, make sure the file you're looking at is now called temp.mdb. If not, you're looking at the wrong file.
This Link Has Full demonstration of Database Connectivity And Publish a C# application with database. The application is also running on another machines.
How to Publish C# Application with access database
We are using Windows Azure to host our application on a Cloud Service and use Powershell to build and package the website using msbuild.
On releasing our first response time is very slow so naturally we'd need to precompile the application.
There's plenty of documentation for Precompiling using the aspnet_compiler, however I cannot find any official documentation on using:
msbuild Web.sln /p:PrecompileBeforePublish=true
A Google search targeted at MSDN gives me nothing whilst usually MSDN is fairly thorough. All I can see is a useful Stack post from earlier this year.
So does anyone know of any formal documentation for PrecompileBeforePublish? Am I looking at the wrong source?
Failing that, what exactly does the flag provide us, is it the same as Precompilation for Deployment with an Updatable UI (reference)?
It's been a while since this question was posted and there is still no good answer. Recently I wanted to change the way MSBuild runs aspnet_compiler.exe but found no documentation. I did a bit of digging around and here is my experience.
Precompiling will only happen if you use both the DeployOnBuild and PrecompileBeforePublish parameters. Other usable parameters are EnableUpdateable and UseFixedNames.
msbuild Web.sln /p:DeployOnBuild=true /p:PrecompileBeforePublish=true /p:EnableUpdateable=false /p:UseFixedNames=true
You can achieve a similar result if you change precompile options in Visual Studio. This can be done at Project > Publish > Configure > Settings > File Publish Options > Precompile during publishing > Configure.
link to image
This is how the parameters should appear in your .pubxml file:
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>False</EnableUpdateable>
<DebugSymbols>True</DebugSymbols>
<WDPMergeOption>CreateSeparateAssembly</WDPMergeOption>
<UseFixedNames>True</UseFixedNames>
Since there is no documentation to be found you might want to change these options and see the resulting .pubxml file to see what further parameters to use in the command line.
I think, your problem is not pre-compilation and I see, you have done precompiling well.
I think your project is too big (Check your final bin directory size) IIS read every dll, and debug symbols and load them in to memory before running any line of code.
If your project size too big, and your virtual environment resorces are low, magnetic disk, low ram, low cpu, so there is no magic in it.
Recommendations:
Try to reduce size of the project output. (Removing debug symbols
can be an option).
Remove all not used references... (Both .net and 3rd Party) (edit, added)
Scale up your environment configuration.
Regards...
rex the solution to your problem is, add a new web deployment project for your website which will automatically pre-compile your website and the project will contain pre-compiled web outputs. If you don't get the web deployment project in your right click please download the tool for Visual Studio with respect to either 32 or 64 bit which will be added to your visual studio Or if you want to do it through MS Build you need to refer to https://msdn.microsoft.com/en-us/library/ms227972.aspx or you can also refer to http://www.asp.net/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/precompiling-your-website-vb
I hope I helped you in some way.
In our project, deployment is always a pain, mostly because of the mistakes done by the release management team. Either they screw up the configuration or get the wrong version installed somehow. We use teamcity as our CI server, and it produces the artifacts as zip files(dll's and exe) which is usually passed on to the release team. My question is, is there a way to automate the whole deployment process?
Is there a commercial tool, which supports this?
We will want to do the following:
Update the config files with environment specific values.
Install windows services to the server.
Upload the UI(WPF) bundle to the centralized location(which is pulled down by another application, sort of a launcher).
Change the DB connection strings.
Do all the above for various environments(like int,uat and prod)
DB deployment since is a separate beast as such, need not be covered in this.
Any best practices, tools or solutions will be highly helpful.
Thanks,
-Mike
I have used TeamCity for some fairly large projects and I have automated every aspect of deployments apart from the database. The main steps I use for each project are:
Get a TeamCity agent installed on the production server
Have the build get everything out of source control (you do have everything in source control right?).
Have a build step that builds and publishes your solution. This can be achieved by adding the following command line argument to your MSBuild call:
/p:Configuration=[Your Config];DeployOnBuild=True;PackageAsSingleFile=False
Your published files (and tranformed config files) will be written to the following directory:
[Your Project Directory]\obj\[Your Config]\Package\PackageTmp
Using a scripting language (in my case Powershell) to copy the published artifacts to your deployment directory and make environment specific changes you mentioned. E.g. extracting archives, copying files, starting/stopping websites etc..
Run any automated testing (e.g. nUnit, Selenium etc...)
I find the best strategy is to have a .Net post-build event that invokes an appropriate powershell script passing in relevant details like the solution path and configuration name (alternatively, I have also had TeamCity pass the environment name to the Powershell script) so that it knows what it needs to do (e.g. Staging, Production etc...). You should find that a scripting language like Powershell can do everything that a person can do (and about 100x faster and 100% reliably).
There is so much content on Powershell out there that you can just google anything you need to do in Powershell and you will get an example. E.g. "powershell deploy WPF", "powershell upload FTP" etc...
In a previous job I needed to deploy windows services remotely and I found that with enough research, I was able to get the MSI for the service to uninstall the existing service and install the new one completely silently (i.e. no dialogs). This will help a lot in your quest for automation. I can elaborate on this if you would like.
Below is an example of a Powershell post build script I generally use:
Note how I use some default parameter values so that I can execute the script directly from my Powershell editor to simulate and test different configurations on my local machine.
param(
[string]$configurationName="Debug",
[string]$sourceDirectory="C:\SVN\<Your local solution location>")
Set-StrictMode -v latest
$ErrorActionPreference = "Stop"
# Load required functions
$private:scriptFolder = & { (Split-Path $MyInvocation.ScriptName -Parent) }
. (Join-Path $scriptFolder DebugBuild.ps1)
. (Join-Path $scriptFolder StagingBuild.ps1)
. (Join-Path $scriptFolder ProductionBuild.ps1)
. (Join-Path $scriptFolder CommonBuildFunctions.ps1)
#Execute appropriate build
switch ($configurationName) {
"Debug" { RunDebugBuild $sourceDirectory }
"Staging" { RunStagingBuild $sourceDirectory }
"Production" { RunReleaseBuild $sourceDirectory }
}
To execute a publish on development machines, I setup a VS publish profile for the solution that is committed to SVN so the other developers can use it. This profile publishes directly to the local deployment directory.
We use TeamCity for our deployments in addition to CI and it works really well. Here are a couple things that may help:
If you're using VS2010, check out the SlowCheetah plugin. It can do the config file transforms to do what you need to replace DB connection strings and other environmental-sensitive variables. These transforms happen automatically when you build based on the selected build configuration.
Check out MSDeploy. While it gets most of it's attention for deploying web applications, it can do a lot of other things, like installing windows services and syncing files to a destination directory. While most people install it as an IIS add-in, it can be installed as a separate service that has no dependencies on IIS.
If you're not using VS2010 (or don't want to use SlowCheetah), here's how we you could handle the config settings:
Create an app config for each different environment (I'm assuming you
have a build configuration set up for each environment). Add the
configuration name to the end of the config file, so in Prod we have
App.config.Prod and QA we have App.config.QA.
Put your complete configuration for each environment in it's respective config file for
that environment.
As part of your build (we use the "BeforeBuild" target in the project file), use msbuild to copy the environmentally specific app.config over the actual one. Here's a custom msbuild target we use to do this:
<PropertyGroup>
<EnvironmentAppConfig>App.config.$(Configuration)</EnvironmentAppConfig>
</PropertyGroup>
<Target Name="ReplaceAppConfig">
<Message Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
Text="Copying $(EnvironmentAppConfig) -> App.config" Importance="high" />
<Message Condition="!Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
Text="No $(EnvironmentAppConfig) found. Leaving App.config as is." Importance="high" />
<Copy SourceFiles="$(ProjectDir)$(EnvironmentAppConfig)"
DestinationFiles="$(ProjectDir)App.config"
Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" />
</Target>
Let me know if you need any other details.
Teamcity + Octopus deploy
Octopus for windows service automated deploys
Our release team uses Anthill Pro - this also has ability to do CI, but they just use it to deploy packages (in our case mostly web site code).
The cool thing about Anthill is the whole client(agent)-server setup, so it traverses firewalls, NAT etc with some effort. And it has approval and scheduling workflow.
As far as configs, this is a different beast - unfortunately both devs and release team have to change these, and somehow merge the result. Consider that you want to add new config key, but release team has to add production settings for DB connection. The trick is that devs are not supposed to know production DB connection string.
So this is not automated (in our case anyways).
I'm partial to TeamCity, which is a Jetbrains product, the company that makes the essential ReSharper (no, I don't work for them, drat the luck). TeamCity, at least last time I checked, is a free product for up to 20 users and 20 build configurations. It has some nice auto-build and blame features. Excellent, really.
You mention a Commercial tool...
TFS, or specifically Team Build, completely supports building the code and deploying it. Whenever we build a web app, it auto deploys to our Dev and QA servers. After deployment we have it run through a suite of web tests to ensure everything is functional. Then the real fun begins with our QA team ;)
Although we don't auto deploy to production, we could certainly do that as well.
I have made an application, which keeps getting updated frequently. So every time a change occurs, i've to include it's fresh builds to the setup and deployment program again and again. Is there any way to simplify the procedure? The files to be added are static in number and exist in a folder. I've heard we can write installer classes in c#, does my requirement has any thing to do with it?
I think ClickOnce doesn't suit my requirement because, for the first time i want it to run like a setup package, since it has some packages and some settings needed to be implemented on the user's machine at the time of install. Can click once help me with that? Also i want to run my application as an administrator and it references to many external dll files. So will it help my purpose?
I finally did it using clickonce deployment. I used content files to mark all the files i wanted to copy to the target computer and used clickonce deployment. Then i modified the way my program starts, so that i can lauch the installer script i wanted to run only when the app runs for the first time. Further i hosted it on IIS and had to change lot of MIME types and add new ones for the download to work over internet
Look into something called "ClickOnce" deployment. It automates a lot of what you're talking about.
EDIT: You can add custom installer actions to a ClickOnce project just like any other, to set up additional components and whatnot. As for permissions, ClickOnce will let you run as administrator if you so choose, but that sort of thing isn't recommended, and it might whine about it.
You can use ClickOnce (http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx) which simplify the deployment process.
Maybe you can also automate the build process using NANT (http://nant.sourceforge.net/).
HTH
Yes, you can do that.
I assume you want the client to update itself when ever there is a new version.
This needs a few changes in the client code. Essentially how it works is check for availablilty of new version at a predefined location. Update you new versions to this location. On the client side, show a message to the user if he/she wants to upgrade to the new version.
You can find a link to sample project out here and here.
You can add a Setup project in your solution inside Visual Studio and then add your other project(s) outputs, or static files to the Setup project as references. The Setup project will then detect your dependencies automatically and each time you do a Rebuild All (or you rebuild/build your Setup project) it will automatically include all the necessary files.
What type of project is it? In many cases, ClickOnce can do the job for you, at nominal effort.
Beyond that - you can usually hook your installer build into your build process; some tools will do this for you.
Installer classes run at the client - so I don't think they relate to your build process...
I would flag the files as Content in their respective properties and then in the deployment project right click the project, go to File System and then right click the folder, click Add and select Content Files from the dialog box. This should copy the newest files over every time you build the deployment project.