I have been working on .net platform for few years now and I must say I am very impressed by how Microsoft is making .net cross-platform compatible.
I spent hours trying to run a small hello world application built using CoreCLR on a mac. And it worked. While There are still a lot of UNKNOWNS I am still trying to understand, there is this one question I was not able to find answer of on google.
How do you automate the deployment a dnx application. I mean, do you compile your aspnet 5 app into a nuget package and then restore it on your linux server (I have never used linux so not sure how nuget works there), and run dnx command ? Or just zip it and push it to the server directly ?
Sorry this is all very new to me and so my questions might sound stupid. I just want to know what's the best way I can implement continuous delivery for my asp.net 5 applications. My ultimate goal is to host my apps on linux containers.
You can use dnu publish --runtime <name of runtime> --no-source. That creates a folder that has your application, its dependencies, and the runtime. Then, all you have to do is get that folder on your server.
How you move files around really depends on your scenario... It could be FTP, Storage, Kudu (if you're on Azure WebSites), etc.
Another alternative is to do the restore on the server. While this reduces the size of the application when you publish, you will have to restore packages on the server which can be insecure and it can also lead to application breaks because there might be newer, incompatible packages on the feeds.
While there's no right answer to fit all, I found that if you want to most reliable and consistent results, you should publish with everything, test locally and then just copy the bundle on your server.
For docker, I recommend the same thing. Publish with runtime and no sources and create a container that has the resulting folder.
Related
I hope this is no duplicate but I couldn't find any related topic. Every developer knows the problem. I create my app, deploy it and on some other machine it does not run because some dependency is missing. Often those dependecies are part of the workloads installed along with Visual Studio or some SDKs.
My question now is if there is a way to test my app on my dev machine like it had not installed SDKs and VS? Basically I want the app to only consider dependencies I explicitely specified through project references, nuget packages or locally copied files. Or in short: every dependency should be part of the app's deployment target folder.
Of course some really basic OS-dependent stuff needs to be used as well but I don't want the app to use stuff like OpenAL, GLFW, Windows SDK or similiar things just because I have installed it on my machine beforehand.
I hope you can understand what I mean. So I basically need some sandbox. I know there are things like VMs, docker, etc but I would like to use this as I run my app from Visual Studio. So if I hit F5 I want the app to ignore globally installed stuff at all.
I work with VS 2022. Thanks for advice.
You could use a continuous integration system in order to build (from scratch), publish and test on a fixed known build agent configuration. I used Teamcity.
You could use a Virtual Machine or a docker image as agent PC.
Moreover you can configure more agents with different possible configurations.
As a general rule of thumb, you can reference Nuget packages instead of assemblies in the GAC. This way, they will be copied to your application's bin folder.
You can also use .NET Application Publishing to create a deployable folder with your application. If you're targeting .NET Core, and the target machine may not have .NET Core installed or you don't know what version it will have, you can create a self contained release which will include the .NET Core binaries in the release.
See https://learn.microsoft.com/en-us/dotnet/core/deploying/
I've built a Winforms Application, and I want to publish it. I'd like to have a link on a website https://sites.google.com/site/satsavvyboardgame/home where I can have the user download the application and have it install on their computer. So far, I haven't found any way to wrap everything up in one package, or successfully publish to the web. What are the specifications for the URL to publish to the web?
Is there any way to package everything into one item (the site won't allow me to upload/download folders), so that the user could download one item, then run that or something in it?
Is there another way to do this that I haven't seen?
I'm using C# Visual Studio 2010 Express, and my application has the code and a couple of XML files that I need to run. All are part of the project, and run fine when I install from a file using the CD publish settings.
I've never published an application before, so any help would be much appreciated. Thanks!
You have 2 general options:
use "ClickOnce" which will enable automatic updates each time the user click to install and have several other benefits such as less problems with priviliges.
Use "Windows-Installer", which allows you more control of how to do and what to do during the installtion phase. However, shamefully, Package & Deployment project types do not exist anymore in vs2012. there are several 3rd party packages you can work with to create your setup-project.
The ClickOnce is preferable if what the user download is a just a simple standalone game application for example.. the MSI is for the more "rich" applications that should make extensive usage in the machine registry and etc..
The table in this link will give you the data you need to make a decision:
http://msdn.microsoft.com/en-us/library/142dbbz4(v=vs.80).aspx
I am developing a C#, MVC4, EF5 Code First application on .NET in Visual Studio 2012 and have used the VS publish mechanism to deploy it to an Azure Website with an Azure SQL Database.
I now want to use Git and GitHub for version control and involve others in the project.
However, although I am familiar with using Git in a LAMP environment, I have no experience of using Git with Windows, Azure Websites and a compiled environment.
I would like to use the Azure Website as the production server, another Azure Website as a Staging server, developer Windows machines using Visual Studio for development and GitHub as the central repository.
There is a helpful article here: http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/ . I can get my head around what would be needed here for, say, a PHP application on Azure. But I am unsure of the best approach with a compiled application and what I can achieve using Azure Websites and Visual Studio.
A nudge or two in the right direction would be greatly appreciated!
don't publish from VS to azure, instead setup your azure website to pull from the github repo. the deployment process compiles your solution.
watch http://www.youtube.com/watch?v=5NGieL0tinw&feature=youtu.be&hd=1 or read http://vishaljoshi.blogspot.com/2012/09/continuous-deployment-from-github-to.html
Also SocttGu announced this on his blog # http://weblogs.asp.net/scottgu/archive/2012/09/17/announcing-great-improvements-to-windows-azure-web-sites.aspx he also talks about a cool feature of publishing branches, this will nail your requirement for a stage server and production server. Have a stage branch and a production branch and merge to them as desired. see the section "Support for multiple branches"
looks like they added support for private repos finally.
appharbor is a competitor to azure that does something similar.
You are basically introducing a new step with the requirement that the source code must be compiled before it can be deployed to the server. Where you implement this step is up to you. You could:
Ensure that your target server has the capabilities to compile the source code (some Continuous Integration tools could help with this, such as CruiseControl.NET). This has the caveat that the target server be able to compile source code (possibly even requiring Visual Studio to be installed), so that may not be an option.
Check the compiled binaries into source control. You could keep these compiled binaries separate from the main source branch, to keep things clean. Deploy the binaries to the target server.
Some hybrid of the previous two options is also possible; you could set up a Continuous Integration server with CruiseControl.NET, which can check out the current source, build it, and check the resulting binary back into a special branch, then deploy that branch to your target Server.
What will I need to use Etsy's Statsd in a Windows Environment? My intentions are to create a .net client to use Statsd.
I have statsd+graphite running in my Windows environment using the C# client NStatsD.
Here are my notes for getting the Linux VM setup:
Note: I know enough Linux to be dangerous but am otherwise a noob and could be doing something unwittingly horrible.
Install Ubuntu Server 12.04. I used VirtualBox for dev and then later EC2 for prod.
Download graphite-fabric to your home folder. This is a script that will download, compile and install graphite and statsd. It expects a clean box and uses nginx for the web server.
sudo apt-get install git
git clone git://github.com/gingerlime/graphite-fabric.git
cd graphite-fabric/
Install prereq's for fabric
sudo apt-get install python-setuptools
The next steps are a download, compile and install which can take some time. It is worthwhile setting a keep alive on any putty ssh session before continuing.
Now install as per gingerlime's instructions in the README.md - including the requirements section.
Install statsd as per gingerlime's instructions.
Reboot
Execute netstat -nulp and observe 8125 is in use to confirm statsd is listening.
Check carbon is running tail /opt/graphite/storage/log/carbon-cache/carbon-cache-a/listener.log. If it isn't, try sudo /etc/init.d/carbon start
Now you have your server running, try throwing some counters at it with the NStatsD client.
Timezone fix:
This will fix graphite to graph times in your local zone
cd /opt/graphite/webapp/graphite
sudo cp local_settings.py.example local_settings.py
sudo chown www-data:www-data local_settings.py (check with ls -l that permissions look right)
sudo pico local_settings.py Set TIME_ZONE to something like Australia/Sydney. Discover what timezones you can use in /usr/share/zoneinfo/
Save and restart the box (not sure how to make it pick up the change without restart)
EC2 Notes
root is disabled on EC2. Fabric prompts for a root password which you don't have. Use the -i keyfile argument with fab to give it your ssh keyfile instead.
VirtualBox Notes
VBoxVMService was handy to automatically run the VM as a service in my Windows dev environment.
TL;DR:
statsd.net is a scalable statsd clone with lots of cool extras, and designed for windows-centric environments. First production release is on the 29th of May, 2013
statsd-csharp-client is a lightweight statsd and statsd.net client, available for .net 3.5, 4.0 and 4.5 via nuget.
Full Disclosure: I'm the author of these two projects and I wrote them because I couldn't take etsy's statsd service to production - my organisation isn't ready to deploy and support nodejs-based services.
I had the same problem in my organisation - we're a windows-centric environment that wants to collect stats from all over the world into a single graphite repository. I had initially thought of using etsy's statsd but my company is not yet ready to roll with nodejs services in production. Along the way I found that having my own aggregation service meant I can do lots of interesting things like add memcached support for scalability, add new aggregators and so on.
The service is usable in console mode right now, and will be ready for production use from the 29th of May 2013 onwards.
Your best bet is to have a Linux server with statsd and Graphite installed. You would then just need to write some C# code to make the UDP call to get the metric into the system.
[UPDATE (6/23/2014): I came across a statsd/Graphite clone called statsd.net that looks promising but largely lacking on the Graphite side of the equation. I still think the best bet is to use the actual statsd/Graphite projects since any clone is necessary playing catch-up.]
We've re-built Graphite/StatsD in pure .NET. It is currently being used in production environment, processing around 600M datapoints daily.
Statsify:
There is quite a few open-source StatsD client implementations available in different Language including C#.NET. Etsy provide one on their github examples, also check out AppFirst version of statsd_clients.
Current statsd and nodejs versions allow you to run statsd on Windows without amendments. statsd package.json file already contains scripts to install and uninstall it as Windows service.
The installation procedure would be:
Install nodejs for Windows
Create a directory like C:\StatsD
Open a console window and do cd \StatsD
Then do npm install https://github.com/etsy/statsd.git
In node_modules\statsd directory create your own config.json
In the console window do cd node_modules\statsd and npm run-script install-windows-service
However, Graphite only runs on Linux.
You need a statsd server to connect to.
You also need a client library to connect to it, e.g. this one and the nuget package of it.
I have a small .NET WinForms application, and couple of linux servers, DEV and CL1,CL2..CLN (DEV is development server and CL* are servers which belons to our clients, they are in private networks and it's a kind of production servers)
I want an update mechanism so that
(1) i develop a new version and publish it to a DEV
(2) users of DEV-server install latest version from DEV
(3) users of CL2 (employees of client2) install stable version from CL-2 directly
(4) application checks for updates using server it was installed from (so, if it was installed from CL-2, it should check CL-2 for updates)
(5) i should be able to propogate the update to a selected CL-server (using just file copy & maybe sed; not republishing), if i want that (and if i don't, that CL-server will have an old version until manually i update it)
I tried to use clickonce, but looks like it meets only first two requirements.
What should i do?
ClickOnce should handle 1-4 to be honest. All that would be needed is that for each site you want to deploy/update from, you'll need it to have its own publish, which after looking at your specifications is not incorrect to do.
What you could then do in order to make 5. applicable, is create an automated process to re-publish the file. This could perform a publish and then upload to the correct server.
Remember that ClickOnce needs a new manifest per version, and a new version requires a publish, so I'm not sure that you'll get around 5. with a simple file replacement.
Kyle is right. But for the 5th note, you just need to copy the deployment, and then use mage to modify the installation URL and point it to the new server, and then re-sign the manifests.
I support an app that we deploy to a DEV, QA, PROD servers. The way I handled this is that
I created created a cmd file that has command line calls to MSBUILD. It builds the app once for each server with the appropriate URLs and switches. I give my DEV and QA builds a different AssemblyName that way I can run all 3 environments side by side. This way my build process is automated and I don't have to publish at all.
Here's an article that describes the parameters you can use.
http://msdn2.microsoft.com/en-us/library/ms165431(VS.80).aspx
#Kyle,
For the above solution can the different versions run side by side or do you get errors indicating the app is already installed.