I'm attempting to automate the build of a source controlled MS Access application (it's only the front-end, the back-end is SQL Server). The Access client is published to the users via a simple C# console app via ClickOnce... It's in that console project that I'm also building the MS Access application via a custom msbuild tasks from this CodePlex library: https://buildmsaccessdb.codeplex.com/ (which is also mentinoed in another StackOverflow post on the subject). On my machine, it all works fine. The Access source code is compiled into an ACCDB, which is then converted into an ACCDE which is what gets included in the published app.
However, when I make it an automated build in TFS, it always stalls at the step where it converts the ACCDB to an ACCDE. I've tried a variety of ways for executing the "Make ACCDE" (SysCmd 603) command. I've tried it in powershell scripts, in VBA, etc... but it always seems to stall. Is that because the automated build process is not an interactive process and maybe the the SysCmd 603 needs to be ran interactively? If I stop the build and take a look at the ACCDB, everything is good. It compiles and can be manually compiled into an ACCDE... so it's not that the ACCDB isn't compilable.
I'd like to test it as an interactive TFS service but I don't control the service account it's running under.
Any tips on suggestions are welcome and thanks in advance! We have this whole automated build and release process up and nearly working except for this one piece!
I don't know much about the MSBuild task library, but from a quick look at the source it looks like it opens Access to run the tasks and interacts with a dialog box at one point. If that's the case you'll definitely need to run the build in interactive mode.
The fact that your build is hanging and not erroring out would also indicate this is the case.
Even though you don't control the service account, I would presume there's someone else in your organisation that does. I'd suggest you work with them and to try the build in interactive mode and ensure it works. If needed you could always set up a second build machine that runs in interactive mode, with the current build server remaining in "run as a service" mode.
Related
I haven't done any cshtml front-end development for a few years.
What's the current, generally accepted way for ASP.NET Core front-end developers to work across a range of tools on Windows?
By that, I mean a way to have the front-end JS build and the .NET project(s) also build and to work rapidly in the browser and code.
My thinking is.
We have much better command line story around dotnet today.
Some folk like VS Code.
Some folk prefer VS 2019, and some like either, depending.
We need to work on UI aspects sometimes.
But we also need to attach a debugger and debug the server logic sometimes.
The build server should have no problem, be simple, and rely mostly on build logic held in the repo.
Tooling, and kicking off the whole build and serve process should be understandable and familiar.
It should be pretty simple to get going after a team noob clones the repo.
My initial thought would be to setup NPM then use something like Gulp to kick off everything, including running dotnet run.
Then when running under the Visual Studio 2019 debugger, use the Task Runner Explorer to kick off the Gulp stuff but skip the dotnet run part.
(shame there doesn't seem to be a command line for start VS(Code or 2019) and attach debugger)
Now I'm expecting to get a "primarily opinion based" SO beating, but there are general trends and ideas that go into designing all these tools for how they can all play ball together and what the dev story looks like.
You've pretty much already described the process. However, I'll add a few things:
You don't need the dotnet run bit. Visual Studio and VS Code are both capable of debugging directly.
You can assign the gulp tasks to build tasks in Task Runner Explorer, so you really don't even then to think about running those directly. I'm not as sure on this aspect of VS Code, but I'm sure there's probably some extension to handle it, if it's not already built-in.
If you want true ease of development, the best thing you can do is use Docker. Just add a Dockerfile to each project that actually runs (i.e. not a class library) and set up the steps to build and run it there. In Visual Studio, you can right-click the project and choose Add > Docker Support, and it will actually generate a ready-made Dockerfile, though you may need to add a step or two to handle the client-side build steps. In any case, this then becomes truly click and run, with nothing to worry about. The story is even better when you use docker-compose, as then Visual Studio and VS Code can spin up your entire application stack all at once, including external dependencies such as a database, Redis instance, etc. If you haven't used Docker before, start now. It's absolutely revolutionary for development.
One note for CI/CD, as much as possible, you should add a YAML file to describe your CI/CD pipeline. Depending on the the actual provider you're using for build/release, there might be some differences, so consult the relevant documentation. (Azure DevOps, for example, doesn't currently support describing release pipelines in yaml, though you can still do your build that way.) In any case, this allows you to configure all this in code, and have it committed to source control.
You may consider the same for your infrastructure. Azure has ARM templates, AWS has CloudFormation, GCP has Deployment Manager. There's also third-party tools like Terraform or Ansible. All of these, in some form or fashion (usually JSON or YAML) allow you to define all the characteristics of the infrastructure you're going to deploy to and commit that to source control. This makes deployment and things like creating new environments as breeze.
This is an extension of an earlier issue I had, which I posted about here: VB.Net Method appears to be called multiple times when it actually isn't, and returns inconsistent results
At that time I had thought the issue was fully resolved, but I've since learned that there were multiple issues. I have worked out all the kinks with the code and logic, and now I've narrowed down the last remaining issue.
Builds will run perfectly fine until one legitimately fails. After that point, all the builds on that specific agent will fail, even if there were no actual errors with the subsequent builds. When they fail, I see the exact same symptoms as I did in the other thread, which I will summarize here:
A method that is only called once appears to be called multiple times as evidenced by the build messages
The build messages will show there is 1 error, but there are no errors in the logs generated by that method (The line to write the error to the log comes immediately after the line where the error is added to the result log, in the same if statement)
Restarting the build service on the build server "fixes" the problem until the next time a build legitimately fails, at which point the cycle starts again
Build server setup:
Windows Server 2008 R2
VS 2010 Premium
Build uses a custom library
There are 4 build agents, one for each environment (Dev, QA, UAT, Prod)
The build and deploy custom library is written in VB using .Net Framework 4.5, and it calls on another library that is written using .Net Framework 4.5 as well.
The build template doesn't use msbuild. It's strictly WF that's been stripped down to the bare minimum and only calls commandline programs (Like robocopy) or custom .net classes.
I have verified that if a build fails for one agent (such as Dev), then all builds using that agent will fail. When it happens, ONLY builds that run on that particular agent will fail, other agents run just fine. I have not had a chance to test yet if just restarting the agent will "fix" it, or if I have to restart the entire service.
I have tried clearing the Visual Studio cache for the user account running the builds, but that didn't help at all. I also have a GUI interface that I designed that does all the same things as the build, and uses all the same code, and I am not able to get it to repeat the behavior.
I've enabled logs on the build controller per these steps: How to enable build agent or build controller’s logs? however they were no help when this problem occurred (There were no errors logged, nothing was different in the logs for builds that were fine vs. ones that bugged out)
I'm not sure what my next troubleshooting steps should be, I know the problem isn't with my code, and I'm having no luck searching the internet via Google, MSDN, StackOverflow, or picking the brains of my peers at other organizations.
I'm wondering if this could be a bug due to running code that requires .Net Framework 4.5 in TFS 2010 build, since it only officially supports up to 4.0.
My advice would be to change the build logger to diagnostic and look at the output, there must be some rubbish being added to the environment.
You can do this with a switch like
/l:FileLogger,Microsoft.Build.Engine;logfile=c:\build.log;Verbosity=Diagnostic
you might want to take a look here
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.
I'm looking at versioning databases and came across the usual articles regarding how to do this (coding horror, ode to code, etc). This all make perfect sense to me, however I'm trying to find a script runner that will run the sql scripts for me. All these articles mention having something to run them automatically, but none of them make any recommendations.
Does anybody know of any utilities for running these scripts? Ideally something that works in the following way:
Runs everything in a transaction so if any single update fails, the whole thing fails
I have control over the name of the scheme version database table
Ability to have a series of scripts that are always run if an upgrade takes place
Can be run as part of an automated task
EDIT
Open Source
We Use DbUp as Script Runner in our Web Project. Its simple and nice open source tools that help you to write you own script runner with Console Application fashion.
DbUp is a .NET library that helps you to deploy changes to SQL Server
databases. It tracks which SQL scripts have been run already, and runs
the change scripts that are needed to get your database up to date.
we can run scripts from folder in filesystem or you can embed them to your assembly and run them as embedded scripts.
you can find more information and sample on their code repository on github.
http://dbup.github.com
Check out SSW SQL Deploy - it would appear to do just about all you're asking for. It keeps track of already executed scripts, it'll run a whole batch of scripts at once and on multiple servers (if required), and so forth.
It's a pretty simple, but nifty tool - highly recommended!
Currently I'm tasked with doing the daily build. We have an ASP.NET 2005 website with a SQL Server 2005 backend. Our current source control is Visual Source Safe 2005.
At this point, I use the brute-force method of daily builds.
Get Latest version of source code
Get Latest version of Database release script
Backup old website files to a directory
Publish new code to my local machine
Run on my server to keep the test/stage site working
Push newly created files to the website
Run SQL Script on test database (assuming updates, otherwise I don't bother)
Test website on the Test Server.
Looking at the idea of automated builds intrigues me since it means that I do less each morning. How would you recommend I proceed? I want to have a fully fleshed out idea before I present it to my boss.
Ditch VSS, move to Subversion, and check out CruiseControl.NET. Alternatively, if you have a MSDN developer license, you can run TFS workgroup edition and set up a build server on any old XP box. Its what we do at our shop.
As Assaf noted, you can use CC.NET with VSS directly. Nice.
TeamCity has worked well for me. It has a very simple setup. Combine it with an MsBuild script for your operations and you're auto-matic.
For build management I wholeheartedly recommend TeamCity. It doesn't require IIS6 (like CC.net does) since it runs on it's own copy of Tomcat and the setup is all done thru various forms. This is a big deal to me since the build server is just an XPPro box. It integrates well with SVN and there is no crazy XML file manipulation like I had to do with CruiseControl.Net. Big win for me.
For a build runner we use NAnt to send emails to various people, copy the packaged builds where they're supposed to go, run NUnit and NCover, and deploy the software to our web farm.
For automated testing we use Watin.
http://www.nunit.org/index.php
http://www.jetbrains.com/teamcity
http://ncover.sourceforge.net/
http://subversion.tigris.org/
http://nant.sourceforge.net/
http://watin.sourceforge.net/
Try CruiseControl.Net. It's free, and whatever customized daily/continuous routine you want it to perform you can always add with scripts.
Remember, it's not just about daily (nightly) builds, but also about letting you catch build errors in time (since it continuously builds after every source commit/check-in). You don't necessarily test every code chance on every possible platform and build configuration, but CC can do exactly that for you (in the background).
http://confluence.public.thoughtworks.org/display/CCNET/Visual+Source+Safe+Source+Control+Block
All of what you are doing can be performed by a set of batch files, depending on how automated your test environment is. The main batch file can be started as a 'scheduled task' at midnight or whatever. That's how we 'do it cheap' here and at other places I've worked. If you need help with a particular batch, I can provide a sample.
I second (or third) the reccomendation for Subversion/CruiseControl.net. Also, if it is appropriate, check out hosted services for SVN like CVSDude. You'll probably become well versed with MSBuild in the process too. Once you get it setup it is great.
The cost doesn't come from licensing of the tools or even hardware necessarily, but from your time building and maintaining the system - and depending on what you are doing, that could become significant.
Start with the basics and incrementally improve it over time. Like anything else, if you try to come out of the gate with lots of automation and functionality you could find yourself mired in it fulltime for weeks.
Whatever tools you use, house them in a virtual machine (ie., vmware).
When the equipment inevitably goes south, you can copy the image onto any machine and not miss a beat because your build server decided to take the day off, assuming of course, you back up.