So I have finished my application, everything works and it has been tested.... but what now? I am somewhat new to C# and I have never been in a position that I am in now.
I have a Windows server that is meant to constantly run this API, so how do I get this application out of VS? Normally I would just copy and .exe of the release build of my apps and run it like that, but that doesn't seem to work.
This sounds like a thing any C# dev should know but I can't find anything on the web, probably because "I am searching wrong", I would be really thankful I someone would show me where I can learn this part of development :D
EDIT: Thank you all for suggestions, I feel like I left out important information about the goals of my API. This API would run locally on my companies network, my employees have a good VPN on all of our devices and they are the only ones who would use the API anyways, so I felt like running it locally is the way to go for now.
You're looking for how to "Publish". This article https://www.c-sharpcorner.com/UploadFile/3d39b4/publish-and-host-Asp-Net-web-api/ will get you most of the way I'd say.
In a (really) rough summary:
Publish your code which will create the files you need a "publish" folder in the source project
Set up a site in IIS on the server (I guess you might need to set up a database too)
Copy the files to the server and make any changes you need to appsettings.json for things like db connection strings.
There are a lot of things that go into this, but with just the information you have given so far, I would suggest reading this article on publishing your API to your server.
The main issue with deployment is:
Will you do API versioning?
How you will maintain the code?
What happens when you change the code e.g. fix a bug or add a new features?
What happens when the new code does not work and you deploy it accidentally, how do you rollback it?
What kind of shutdown time is allowed?
Do you need continuous integration?
Do you need docker?
Do you need cloud?
etc...
People usually write automated deploy code nowadays, so it is not as simple as just running the code on an IIS server normally, though it depends on project size or how serious you and your bosses take it.
REST API versioning: https://www.xmatters.com/blog/blog-four-rest-api-versioning-strategies/
MsDeploy to IIS: https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/web-deployment-in-the-enterprise/deploying-web-packages https://dennistretyakov.com/setting-up-msdeploy-for-ci-cd-deployments-to-iis
CI servers: https://www.ahmetkucukoglu.com/en/how-to-publish-asp-net-core-application-by-using-jenkins https://www.alibabacloud.com/help/en/web-app-service/latest/08d871 https://octopus.com/docs/guides/deploy-aspnet-app/to-iis/using-octopus-onprem-teamcity-builtin
Cloud: https://learn.microsoft.com/en-us/azure/devops-project/azure-devops-project-aspnet-core
Some db versioning tools: https://www.liquibase.org/ http://dbdeploy.com/ https://flywaydb.org/
Related
I have an existing Umbraco-project running on an IIS-server. When I started the project I basically installed Umbraco directly to the server and coded through the Admin-interface until the site was launched and went live.
Now, the customer wants some changes and it feels like I've painted myself into a corner here, since I obviously can't make changes in the code while the site is running. So, my question, which I hope this excellent community can help me out with:
How do I proceed when I get a copy of the project locally, to develop in Visual Studio and then publish it back to the live server? Should I create a GIT-repo, or is WebDeploy an option? Which workflow is the most convenient when developing and maintaining an Umbraco site?
I am also quite insecure about what configurations are needed on the IIS-server to support deployment from my local machine, so some input about that would be much appreciated!
Don't tell anyone, but for file updates only (like stylesheets or templates), I sometimes just FTP them up or publish to file system and copy/paste the files via RDP. If you make changes to document types etc., consider if you can't just test them locally and recreate the changes in the live environment afterwards.
Of course, this is only viable for small changes/solutions and one-man teams, but I feel that it's perfectly okay since the alternative(s) get very complex very quickly.
Edit: and also it requires you to keep your local copy pretty close to the live one, so you can be relatively sure stuff doesn't break when you "publish".
You'll have to get a copy of the files from the server, but also use a local copy of the database and update the connection string in web.config to point to that, otherwise any backoffice changes you make will be made on the live server.
If you are just making changes to views then some kind of publish from visual studio will probably work, but if you are making new document types, macros etc., this also involves data changes in the database which won't be published from visual studio at the same time.
There are various tools out there which cater for this situation of making development changes and moving them to live.
The obvious one is that you repeat all the changes you made in dev on the live server, although this can become tedious if there are lots of changes.
There are also things like Umbraco Courier and another one which I can't remember the name of for the life of me that copy all the relevant things from dev to live in one go.
I have a unit testing framework for WP7 and it runs on the phone. The results are fairly hard to read so I am writing them to an XDocument.
My question is, how can I then get this XML file off of the phone and onto my desktop where I can actually analyze the results?
What I have done so far is to put a Debugger.Break() line right after where the summary xml is created. I can then copy/paste the xml out of VS or inspect it right in the debugger. The problem is though, that if you don't already have a debugger attached (which is good when lots of ExpectedException tests) Debugger.Attach() seems to not work, also manually attaching VS to the emulator processes seems to do nothing.
I tried running the emulator with some extra command line parameters so I could try to see if I could get it to use my actual hard drive as it's own disk but I couldn't seem to get it to work...
PS it's probably not reasonable to pop open a new process such as a webserver to listen for this data. I know how to do that, I would just rather not.
So how the heck do you get stuff off of these phones??
Have a look at this article about emulator automation from Justin Angel.
It includes details on how to remotely read and write files from/to emulator/device isolated storage.
As you pointed out the other alternative would be to have the applciation send the results to a [local] web server.
The article by Justin Angel is really great, but unfortunately his file-based solution does not work on the final RTM versions of the CoreCon API. Microsoft has simply removed that functionality from the native conman layer.
I've been in the same situation as you and have contemplated various ways to get data out of the device, but in the end only one thing seems to work: as you suggest yourself, pass data to an external webservice.
That solution is less than ideal not only because it takes some effort, but also because of a few caveats:
your app must be granted ID_CAP_NETWORKING capability
network-traffic seems disallowed in the Application_Closing event, and maybe elsewhere too
On the bright side I found that webrequests from the phone, both hardware and emulator, were really fast so the approach works very well (our app is EQATEC Profiler for WP7).
I have a system with two web applications, one web service, one Windows service and a WPF application running 24 hours a day on a touch screen. All of them are connected to a database.
I want to be able to upgrade all of those applications by uploading upgrade files to the database and set the date and time for the upgrade to occur.
I have one idea on how to do this.
An application has a thread running to look for available upgrades.
When an upgrade is found, the file is downloaded to the application's computer.
When download is complete, the applications triggers a restart.
When application starts, it looks for an upgrade file on the local computer.
If upgrade is available, the application upgrades itself.
I'm not really sure how all these steps should be done yet, especially the last one. But I want some comments about this. Is this completely wrong? Am I on the right track? Any tips on how to do it like this or in another way?
I think you're going down the right lines here. A polling application to check the database for the existence of a new update followed by an xcopy deployment script would do it.
This might be doable from a PowerShell script too, that runs on a schedule, say every 10 minutes. It could check the database, close the process and service, xcopy the application (from a shared source) and restart the said service and app.
All this assumes that you are not using Windows Installer to package and deploy your application initially. Although an xcopy to directly replace binaries wouldn't hurt an MSI package, it's not recommended. We use AD MSI deployment at work and it's a pain at the best of times!
MSDN contains references for MSI vs XCopy deployment for WPF applications (as well as the security requirements).
This was the first link I found for querying SQL from PowerShell: http://elegantcode.com/2008/03/27/discovering-windows-powershell/
Good luck!
You will have trouble doing this with ClickOnce. ClickOnce would only work for your WPF app, it can't do anything with the services or web application. You could write a separate ClickOnce-deployed "Updater" app whose job is to update the other apps, but that still seems a little iffy.
It may sound stupid, but I'd start with the simplest thing I could think of. How about using Dropbox to push your update files; then an AutoHotKey script that runs on startup, watches the Dropbox folder for new updates, and runs them?
Sounds hokey, but it's something you could prove out in an hour or two.
Microsoft have an Updater Application Block which might be what you are looking for.
Do you really want to run an update from the database or is this just a possible solution? You are reinventing the wheel.
Have a look at ClickOnce deployment, everything you need is already done for you and integrated into VisualStudio. If you use something that already exists you have the benefit of existing documentation, helpful blogs of people who have already gone through the pain points and updates and fixes.
ClickOnce Deployment
ClickOnce Deployment in .NET Framework 2.0
How you want to use ClickOnce depends on what you want to get out of it. Out of the box you can very easily create a deployment that checks for an upgrade every time you run the application but you can also with a little bit of code have the application check for updates whilst it is running.
The Updater Application BlockVersion that Dominic Zukiewicz mentioned is the pre cursor to ClickOnce.
EDIT
ClickOnce provides a roll-back scenario on both the Server and Client end. The client can roll back to a previous version using the normal add remove programs dialogue and you can easily republish a previous version.
You could create another Windows Service that does the updates on a daily basis. The service would look on a specific folder if there are any updates to be process. For example it could look for an xml file which tells it the new version of the application and what the files to update are. It would shut down the application/services, backup the files that it needs to update, start the application/services, and clean up backup files keeping at least three backup files. The service should keep track of the last and current version installed so that when it reads the xml file it can check if it is a new update or not or you can simply delete the xml file when it completes.
How about Google Omaha? It's an open source tool, currently used to push updates of Google Chrome and Google Earth. Omaha can handle application installation, too. A high-level design overview can be found here.
Hello I recently deleted what I thought was an unused folder which happened to have the solution and code for a windows application I am maintaining.
I have published the app multiple times with ClickOnce and have access to the application manifest, deploy, etc. Is there a way for me to use the published application to get back my solution?
Thanks
If you don't currently use source control, I would highly recommend using one. I'm not aware of a way to get back all the solution files without source control, but you can get back the code using .NET Reflector. There is a file disassembler add-in which allows you to dump the code straight out of Reflector.
not possible. you can't recover the solution and original code from the compiled and deployed version.
if you have not used that machine or hard drive since you deleted it, you may be able to recover the files but it's a long shot and may be expensive.
you need to invest some time in learning source control. git, mercurial, subversion... they're all free and easy to use in windows. having your code in source control would prevent this problem - delete it all you want, just do a checkout from source control again.
Just go get the project back from Subversion.
Basically all you can do at this point is feed the assemblies to a program like reflector and reverse engineer it back. Welcome to sucksville.
If you don't have your stuff in some type of repository already I'd highly recommend fixing that first thing in the morning. With free tools like subversion available, nevermind things like TFS or even VSS there just isnt a good excuse.
What would be the Most secure and Safe way to allow software to auto-update without opening too many holes to enable a hacker easy access to a system?
Have you looked into ClickOnce Deployment?
http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx
The short overview is here:
http://msdn.microsoft.com/en-us/library/142dbbz4(VS.80).aspx
I recommend not building your own auto-update, use ClickOnce if it works for you or a commercial auto-update component if not.
If you want to see what is involved I wrote a series about writing an auto-update component on my blog some time ago, the last post with links to all the posts in the series is at: http://www.nbdtech.com/blog/archive/2007/08/07/How-To-Write-an-Automatic-Update-System-Part-8.aspx
If you are going to make your own system then you will probably want to have a public/private key pair.
So, you would zip up the update.
Then encrypt with the private key on the server.
The client can then decrypt and unzip it, and then install it.
That way, as long as your private key is secure then you can ensure that the update is legit.
The only weakness here is that if someone changed the public key to some other key, then they could fool that program into thinking that a trojan is a valid update.
There are various schemes you can use to get around this, but that would depend on how much work you want to put into this.
ClickOnce auto update is all fair and well but anyone can admit that it is not the most of fashionable solution. I've recently developed a solution that requires such an auto-update feature. Here is a list of brief steps I took to deploying my very own updating service that also allows for roll-backs with 'minimal' know-how.
Add a Setup project to the solution so that the project could be wrapped up neatly in a .exe or .msi installer package.
The following is to setup a FTP server with your desired user credential that only your application knows. On the ftp server, setup a default directory for where you will put any new updates.
Your application will check for internet connection on start-up, log into your remote FTP server and check for any new files to download.
Download new updates to your client application and put them in a date-time named folder for future reference. Some checks need to be in place to make sure that you don't download the same old files.
Close the application and run the new installation. Depending on how you setup your Setup project, the installation wizard may remove the previous version completely or just update partial (patches, etc.).
Your application may have a feature to roll-back to previous version by going into the local update directory and fish out the previously downloaded files. This is where the date-time stamped files come in handy for reference.
This solution offers a level of customization that I think most Enterprise solutions will need and I found that it works very effectively for me. FTP servers are secure and reliable as far as file downloads are involved. You can find a lot of FTP download helper library on the internet so its a matter of making work the way you want and not worry too much about how it works.