I have a ClickOnce application that needs to be setup from several URLs. For example that I need it to be installed from the following URLs:
http://mycompany.com//url1
http://mycompany.com//url2
I publish it based on installing from url1 (publish wizard -> page two -> from web specify the URL: url1), but when I try to copy it to url2, it still looks at url1.
To do this, I set the installation folder URL to
http://mycompany.com//url1
and checked Exclude deployment provider URL and published the application to a directory on my pc and then I copied it to the server.
How can I force it to use url2 when the installation is started from a index.html on url2?
Edit1
I did several tests to see why what is happening.
The publish wizard creates a HTML file called index.htm.
In this HTML file, there is a button that has a reference to setup.exe. When this application runs, it looks for .application from url1. I checked and there is no reference to url1 in the HTML file, but setup.exe looks at .application from url1.
If I delete all files from url1, but all of them exist on url2, the application setup fails by an error that it can not find http:\mycompany.com\url1\myapplication.application.
If I create a new version of the application and upload it to url1, then go url2 and try to install it, the newer application is installed, but no update happens.
My settings are:
Options:
Deployment
Automatically generate deployment... Set
Open deployment web Set
Use .dep file ex Not set
For CD installation, aut Set
Verify files uploaded to a web sever Not set
Manifests
Block application from Not set
Allow URL parameters to pass Not set
Use application manifest for trust Not set
Exclude deployment provider URL Set
Create desktop shortcut Set
Publish location
publish/
Installation folder URL
http://MyCompany.com/url1
This application is available offline Set
Publish wizard
How the user install the application:
From a web site URL =url1
Yes this application is available online and off line set.
That is really weird - please make sure you indeed deleted everything from both URLs. After you generate ClickOnce deployment files with "Exclude Deployment Provider URL" option, there is no mention of the installation URL in the <<your application name>>.application file - so from my point of view, there are two possible scenarios:
You copied the wrong (old) deployment files into the URL2 folder (or did not override them).
You are doing a manual update from your application with URL1 hardcoded somewhere.
In my case exactly same scenario works as it should work - multiple URLs - multiple installations.
Related
I noticed a behavior I don't understand happening with my application's ClickOnce deployment: a database file (Main.accdb) that is marked as a data file isn't replaced in C:\Users\username\AppData\Roaming\AppName after re-installing or installing a newer version.
In the Project Properties > Publish > Application Files I have:
File Name App_Data\Main.accdb
Publish Status = Data File
Download Group = (Required)
Hash = Include
In the file properties I have:
Build Action = Content
Copy to Output Directory = Copy always
When I install my WPF application using ClickOnce the first time, the file is found in C:\Users\username\AppData\Roaming\AppName. However, if I uninstall, delete the file in that folder, and re-install it is not replaced. In fact, anything removed from that folder isn't replaced by re-installation.
I tried various options for the Publish Status but the same behavior happens regardless of which options I choose. I'm using WPF with C# in Visual Studio 2017.
Why is this happening and how can I make it so that the file is always there when the application installs (or even better, launches)?
It turns out that the App_Data folder behaves differently and the issue can be resolved by using a folder with any name except App_Data.
I can't find this documented anywhere except for a handful of forum posts of users with similar issues, however, I was able to verify that it all works exactly as expected once I changed the folder name.
All that being said, Microsoft does seem to want developers to use App_Data for databases, so perhaps this is an exception to the norm and may not be the right approach for most projects. In my case, it's a desktop application that needs to deploy a local Access database to the user's computer on install and keep it up to date/replaced during re-install and updates.
I'm trying out ASP.NET 5 and all its new features on VS 2015 Enterprise RC. To ensure smooth end-to-end deployment, I then try to deploy the application to a non-Azure private server through VS Publish feature.
However, I'm missing out a very important feature: the ability to publish to a non-Azure server.
In earlier versions of Visual Studio (I'm using VS 2013), the Custom options is there.
I've tried tinkering with the Project Properties but nothing on how to deploy my ASP.NET 5 app to a custom server. Any ideas?
It's doable (after all, publishing to Azure websites also uses WebDeploy internally), but it's kinda tricky right now and requires you to tweak a few things.
Here's what you can do (for VS 2015 CTP6):
Preparation
Asp.net vnext has slightly different directory structure than a regular Asp.net app. The are two main directories: approot and wwwroot (if you deploy the application to local filesystem, you can browse through them). We want to deploy both those dirs, but the IIS website path has to point to wwwroot dir. This problem seems to be addressed in Web Deploy 3.6, but i will just deal with it manually. In order for this to work, you can create two websites/applications in IIS:
one that points to the root application dir and will be used just for deployment. I will name it mysite-deploy.
one that will be used to actually host our website and will point to wwwroot dir. I will name it simply mysite.
Deployment
Go to YourprojectDir\Properties\PublishProfiles
Create an empty pubxml file (i.e. mysite.pubxml)
Paste the following content into your pubxml:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
</PropertyGroup>
</Project>
When You press "Publish" in Visual Studio, you should see this new profile on the list.
Fill out the Connection tab, as you would normally do (set Server, Site Name, etc.). Remember to set Site Name to the deployment site (mysite-deploy).
Validate Connection
Try the preview tab - it most probably wouldn't work, but in case it does - you're done.
Click Publish
Check progress in the Web Publish Activity window.
Possible errors
Out of the box, the publish will probably fail. Now it gets tricky :)
ERROR_FAILED_TO_DESERIALIZE
At first, what I've got is this error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.AspNet.Publishing.targets(205,5): Error ERROR_FAILED_TO_DESERIALIZE: Web deployment task failed. ()
Publish failed to deploy.
Let's try to fix that.
Open the Publish window again, and check Publish using Powershell script option on the Settings tab.
Try again.
ERROR_CERTIFICATE_VALIDATION_FAILED
If you get an error: ERROR_CERTIFICATE_VALIDATION_FAILED, this means that the SSL certificate that IIS Management Service on your target machine is not trusted by your computer. You can try to download the certificate add it to trusted cert store, or you can disable certificate validation altogether.
In the latter case, you need to edit publish-module.psm1 located at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\1.0.0-pre\publish-module.psm1. Find the fragment:
# add excludes
$sharedArgs.ExtraArgs += (GetInternal-ExcludeFilesArg -publishProperties $publishProperties)
# add replacements
$sharedArgs.ExtraArgs += (GetInternal-ReplacementsMSDeployArgs -publishProperties $publishProperties)
And add this:
$sharedArgs.ExtraArgs += '-allowUntrusted'
ERROR_COULD_NOT_CONNECT_TO_REMOTESVC
Inspect the exact commandline that is getting invoked - in Web Publish Activity Window there should be a line logged, starting with Calling msdeploy with the command:. Look for ComputerName=. If it looks like this: ComputerName='https://https://myhost:8172/msdeploy.axd'/msdeploy.axd', then you should changeServerfield in Publish profileConnectiontab to:myhost:8172. That's because the powershell script automatically addshttps://and/msdeploy.axd`.
ERROR_PROVIDER_NOT_FOUND
More Information: The provider 'contentPathLib' could not be found. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_PROVIDER_NOT_FOUND.
Go again to C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\1.0.0-pre\publish-module.psm1 and find the line:
$publishArgs += '-enableLink:contentLibExtension'
This seems to be a feature of Web Deploy 3.6, but it seems that the server side has to support it also. To disable it, just comment out this line. Warning: This change may impact powershell deployment to Azure websites.
Only the content of wwwroot directory gets deployed
Now that your site is being deployed, there is one more thing. We wanted to deploy approot and wwwroot directory, and instead only the content of the wwwroot directory is deployed. To fix that, we need to once again edit C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\1.0.0-pre\publish-module.psm1.
Find the line that says:
$webrootOutputFolder = (get-item (Join-Path $packOutput $webroot)).FullName
And after that, add a new line:
$webrootOutputFolder = $webrootOutputFolder | split-path -parent
This will set the published folder to the parent of wwwroot, which is exactly what we need. Before publishing again, you may want to clear your site's directory on the server - the published directory structure will be different now.
Testing
At this point, the site should be deployed and available on the server. On the server side, you should see two directories: approot and wwwroot and maybe some script files.
Any server side errors you will have to debug yourself.
Setup: MVC Web Api app, Visual Studio 2012
Folder layout:
D:\WebSites\MySite\bin\MyDLLBin\Some.dll
My application needs to LoadLibrary on an unmanaged DLL as part of a MVC Web API application. Before doing the LoadLibrary, I do a:
File.Exists(#"D:\WebSites\MySite\bin\MyDLLBin\Some.dll")
And this returns false which means I should not do the LoadLibrary.
I tried copying the DLL here:
C:\MyDLLs\Some.Dll
and
File.Exists(#"C:\MyDLLs\Some.DLL")
returns TRUE. So I do a LoadLibrary from there and everything is goodness.
I created the "C:\MyDLLs" folder by logging onto the server and creating it. The "D:\WebSites\MySite\bin\MyDLLBin" folder is created via Publishing from Visual Studio.
I think maybe some kind of permission problem, but I have logged onto the server and set "Everyone" to "Full Access" on every folder in the path "D:\WebSites\MySite\bin\MyDLLBin" and the File.Exists still fails.
It would be better for me to deploy Some.dll as part of the publish to the bin folder and not have to create a special folder on the server to hold the dll.
Can someone suggest a fix or some other things to try?
UPDATE #1:
Interestingly:
System.IO.FileInfo(#"D:\WebSites\MySite\bin\MyDLLBin\Some.dll").Length
does not throw an exception and returns 7132045.
Assuming that filePathInApp is the string holding the path to your file from the root of where the application is running (as opposed to the root of the file system),
Server.MapPath(filePathInApp) will alter your directory path to be "rooted" wherever the application is running. So you may want to try Server.MapPath("some.dll") or Server.MapPath("\MyDLLBin\some.dll")
I have installed a C# Windows Service on Windows Server 2008. I installed it with InstallUtil. The service reads some data from the app.config file and it is doing it fine. Can you tell me where this file is located after installing the service?
I have been looking for hours but can't find it.
You can verify the exact location of the installed Windows Service by following the steps below:
Bring up the list of Windows Services by clicking the "Services" icon under the "Administrative Tools" icon. You can also get this list by typing "View local services" in the Search Menu under the Start Menu.
Select your Windows service in the list of installed services, right-click and then select Properties. You can also double click on row representing the service.
Locate the "Path to executable" value on the Properties dialog box. The value will include any command line parameters.
Open the folder in which the service executable resides.
If the Windows service has been built with .NET Framework, its configuration will be stored in the corresponding .config file, i.e., the name of the executable suffixed by ".config", e.g., if the name of the executable is "XyzService.exe", then the name of the .config file will be "XyzService.exe.config".
A couple of things to note:
If you installed the service after building it on the same machine using say, Visual Studio, then Visual Studio would have transformed the App.config file from the project and placed it in the build output folder automatically (and renamed it appropriately using the above naming convention).
If your machine is set to hide file extensions in Windows Explorer, you will see 2 files "XyzService" and "XyzService.exe". In this case, the "XyzService.exe" is your config file. If you then switch off the option to hide file extenions in Windows Explorer, you will then begin to see "XyzService.exe" and "XyzService.exe.config".
If you cannot find a corresponding .exe.config file, then it is possible that the code within the service is falling back to default values. In this case, you can place a properly named and formatted config file alongside the service executable and then restart the service and everything should be fine.
According to Microsoft
For client executables, the application configuration file resides in
the same directory as the application's executable and has the same
base name as the executable with a .config extension.
Note, if your exe is called appname.exe, and you have Windows explorer set to hide extensions, then your application will display as appname and your config file then it will be displayed as appname.exe (even though the true name is appname.exe.config)
As others have pointed out, InstallUtil doesn't do anything with the config file and it should have copied to the server in the same manner as the exe itself.
It is the same location from where you have registered service using installutil tool.
The App.config is likely called {ProjectName}.exe.config given the fact that it is a Windows Service. Check to see if that file exists and is what you are looking for.
The same place where your application (Windows Service) is.
Check it out, if it's not there place it in the same directory as of service.
If you have a live environment (and from your question it seems like you do), you can check what's actually happening using the superior Process Monitor utility. But usually the .config fileis located right next to the .exe, and named the same.
I have a Visual Studio 2008 solution with an ASP.NET Web Application project. I want to change the default output folder, of said project, to $(SolutionDir)\WebApps\$(ProjectName)\bin. This I can do and when I build I get the expected assembly files in this folder. It doesn't copy the content files (aspx, etc.) to the parent folder but I have managed to fix this by hacking the project.csproj file with a custom build target.
The problem is I want to be able to debug this application using the ASP.NET Development Server, by pressing F5 in VS2008. Unfortunately the ASP.NET Dev server starts, has a "Physical Path", in the project directory rather than the parent of the output directory.
Is there any way to build my web application to a different output folder but still run the asp.net dev server to debug my site?
Thanks.
Short answer is yes, but it isn't pretty. The process I used is given below.
Unloaded the project in VS.
Manually edited the .csproj file to include a post build action that basically copies the content files (aspx, etc.) to the parent of the output folder.
For the debug options I set the project to launch an external executable. The Asp.Net Development server. Also manually set the url to launch.
What I learnt? I wouldn't do this, I'd just stick with the default and create an install/web deployment project instead.