I'm publishing my app with ClickOnce to a web server, with the install from a web page option. But I usually have to try it like 5 times before it works because I'm using a not very good server, and it is a lot of files that are being uploaded. Also maybe since there is no bandwidth limit on the server that's the way they say "hey, easy with the bandwidth". Whatever.
But now I've been trying to publish for like 2 days already and I always get an error, always something with the server. So is it possible to publish to my own PC as if it were a server and then upload my files manually, without having to manually create a manifest and stuff like that?
Yes. Set the publishing file location to a local directory, like C:\MyApp. Then set the installation URL to the URL the users will use to access it on the webserver. Publish it.
It will publish the files to the local folder.
Copy or FTP the new versioned folder up to the server first. This is under "Application Files", and will be something like yourappname_1_2_3_4 where 1.2.3.4 is the version number (for example).
Next, copy setup.exe, publish.htm (if you're using it), and yourappname.application to the root of your deployment folders on the server, overwriting the ones that are already there.
The version the user runs is determined by that deployment manifest (.application file) in the root of the deployment folder, so the versioned folder will not be accessed until you put the new deployment manifest in place. That's why you want to do the versioned folder first. Obviously if you put in the new deployment manifest and the folder it wants to use is not there, you'll have a problem.
Related
I did the following steps:
I have created a new Umbraco instance by using the nuget package and visual studio.
I have deployed to Azure, using Azure DB as backend.
Installed the articulate package.
Added my project to version control (including App_Plugins folder, articulate dlls and so on).
I am able delete the umbraco installation and I can restore it completely from version control including Articulate.
Now I am starting to add content, articles, pictures and so on.
Think I do not need to backup the whole folder on the web server. I am doing regular backups of my Azure DB and I need some folders which are also filled with new content, like
media (filling with pictures which I am adding to my articles)
App_Plugins (keeping installed packages in umbraco)
App_Data/packages (file directory for installed packages)
App_Data/umbraco.config (keeping some content for Articulate)
So, is this everything I need to be able to restore the whole system by using the version control part, azure db backup and the listed folders?
Ideally for data/contents you should backup media and App_Data folders. However, if you want to backup Umbraco site (including cache files) then I would recommend App_Plugins, App_Data, Bin, Config, Umbraco & Umbraco_Client folders.
Hope this information helps!
Basically I follow the approach as described in the question. I have added the following files and folders to the Visual Studio project and then later to version control (I have just expanded the more interesting folders which are not part of the project file by default, but needed when you redeploy the solution from scratch):
As described the backend is hosted on Azure SQL.
Open Live Writer makes it very easy to host article content on another ftp server.
By following this approach it is very easy to redeploy the complete solution, e.g. for umbraco upgrades or major changes on the site.
In my company 3 developers use PhpStorm for developing WebApps.
Everyone needs to open (not simultaneously) a project an other user created from time to time.
Let's say user A uses a deployment server named server A and user B uses server b.
User A created the project in the deployment.xml server A is saved.
Now user B needs to open the project and creates server B. Now server B is saved in deployment.xml
If user A want to reopen the project again, he has to set the server back to server A.
Same goes for the workspace.xml.
My question is if it possible to use different project settings for user A and user B?
If it is possible what do I need to change in my settings?
If not how can 3 users work together (no VCS)?
Thanks in advance
In the case where no settings are to be shared between developers, only the project files, PhpStorm accepts reading project files from a directory outside of the classical 'project directory'. Here is one approach to that; each developer is to:
Create and open a new empty project from PhpStorm, in a folder on the local hard drive. Only project settings will be stored here.
Open the Settings dialog, choose 'Directories' from the left pane, then click 'Add Content Root' (at the top of the rightmost pane).
Choose the folder on the network share that contains the project files.
Remove the original 'content root' corresponding to the project settings folder on the local hard drive.
Each developer can now open their locally created directory in PhpStorm, and any files opened/created will exist on the shared folder.
A related question: PhpStorm - How can I avoid creating the .idea folder?
Please note that working with files that are not on a local filesystem, especially when they are editable by multiple developers, is not recommended. Even for small projects, storing a Git repository on the network share, with each developer git pulling when beginning work and git pushing when done, is a small investment that will pay large dividends. Here is a good introduction: http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/, but the key command is git init --bare reponame in the setup phase.
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
When using Clickonce deployment when the publishing wizard in Visual Studio asks if the application will look for updates online (and if so, to provide a url) what exactly should I point to? Do I simply host the contents of the /publish folder on a server, and enter the url to that folder? Then just update the online /publish folder when I release updates, or should the url point to something else?
Normally the best way to host a ClickOnce Deployment is to deploy from a webserver.
On the first page in the Publish Wizard where it asks Specify the location to publish the application leave this as Publish\
On the second page where it asks 3 options select the top one marked From a Website and type in the url of the web server where you want to deploy from (this needs to be the full uri inc virtual directory).
Then complete the wizard.
What you should end up with is a series of files in the Publish directory, one of which will be publish.htm
You can then upload these files as is to your webserver and give out the link to the publish.htm file to let your users start the installer.
If you re-publish just keep the settings the same and you should roll out a new update to all those people who used the publish.htm link to install.
I have the following setup:
Main Website - MVC 3 project, to be hosted on www.domain.com
Intranet Web App - MVC 3 project, windows authentication, hosted on admin.domain.com, which is only accessible from within the local subnet.
CDN Website - A simple web app that merely serves images to both of the above. It will be hosted (publically) on cdn.domain.com, when we go live. I have set up a local project to mock the CDN during development.
I've written a business layer that allows users in the admin panel to upload images, which are then physically saved to the CDN path that's configured (currently on the local machine i.e. C:\Code\SolutionName\CDNProject\images). The main website then uses the same business layer to find and distribute the images via http://cdn.domain.com/images/. http://cdn.domain.com is currently set to http://localhost:55555, while we develop.
Whenever an image is created via the admin panel, it is physically created on disk. Each developer works on his own machine, we we want to be able to check these files in to TFS, for the time being. As you might have guessed, adding files to the file system does not automatically reference them in the project:
I thought there may be some way to reference these images as resources, or set a directory to a "content" directory of sorts... but I can't find anything.
Some developers work remotely via VPN, and do not have access to the local network (only TFS), so a network path is not an acceptable solution.
I thought I might be able to set a pre-build event up, to add all files in a directory to the project?
There is no very easy way to do that. There are a few ways to think about:
1) Write VS adding which adds new files to project (via DTE - starting point). Find out how to automatically run this VS addin on Pre-Build step. Install this addin to your developers machines.
2) Extend your admin logic to automatically check-in the uploaded files to TFS via TFS API
3) try to apply more sofisticated techonologies like this one: T4 Tutorial: Integrating Generated Files in Visual Studio Projects
Hope that helps,
Visual Studio project files have an XML syntax. Project file properties can be modified in a simple text editor (files added/removed, etc.).
You can create a script to open your solution, and before actually opening the solution, you can scan that directory and "inject" the files (with the appropriate XML tags) in the project files.
I don't think you can add this as a pre-build event because the project files are already loaded at that point, and you cannot modify them while they're used.