I would like to be able to publish from visual studio. I am able to do this
I have different configurations for Debug,QA,Release. I am using config transforms and they work fine.
ISSUE: when I publish the I want the Debug, QA,Release to be published to their respective folder example E:\Application\Debug and so on. I am able to do this by changing the Publishing folder location and Installation folder location manually. How can this be such: f I change the configuration these locations are selected automatically. So when I need to publish a particular version -> and all I need to do is
change the config
press the publish now button.
Thanks!
The only possibility I know of would be to use a Build Server and build if the Source code changes (probably seperate branches) and have build definitions for each case.
This would mean that you would have to have a kind of source control (Git, Mercurial, TFS) for the Project and the resources to run that kind of service or use a Service on the internet.
Build Server for local installation:
TeamCity
Team Foundation Server
Build Server via Internet:
VisualStudio.com
(Those are the onse that come to my mind because I have used them before. There are much more available)
Related
So I was able to publish my wpf application using click once without any problem for a couple of months. But yesterday when I tried I got an odd looking message.
When choosing Yes option the publish stops and fills error list with those errors:
I tried searching online but without any success.
I resolved this issue by unchecking the passive mode check box when prompted for the ftp credentials
This issue started happening to me after I upgraded to Visual Studio 2019 16.7.3. I also updated my application from .NET Framework 4.7.2 to 4.8. (Although I doubt that's the issue, I did not revert to 4.7.2 to test it.)
My solution was to publish to a local folder and then upload those files with a separate FTP application (e.g., FileZilla). Upgrading my existing ClickOnce app worked fine.
Details: In your application's Properties page, select the Publish tab. Change the Publishing Folder Location field from "ftp://whatever" to "C:\publish-MyApp." Click the Publish Now button. VS will create the files pretty quickly. Next, use your FTP application to upload the contents of the C:\publish-MyApp folder to the existing installation folder on your server. This overwrites the existing setup.exe and MyApp.application files and adds a new folder (e.g., MyApp_1.2.3.4) in the Application Files folder.
(One side benefit of this method is that it's faster to publish because FileZilla is a lot faster at uploading than Visual Studio.)
I have created a WPF desktop app and generate MSI build using Installshield. I have created an MSI setup to install my app in C:\MyApp\ location instead of using program files. It is working fine as expected.
Then I have generated & tested a UWP app using the same InstallShield project. Installshield 2016 supports Desktop Bridge integration to do this - http://learn.flexerasoftware.com/IS-WBNR-InstallShield-2016-Whats-New.
I have noticed that the UWP app installed in the default location (C:\Program Files\WindowsApps) instead using the location defined in Installshield.
I want to change this location from my InstallShield project. Please help me to find a way to resolve this problem.
For UWP apps, we can't change their install location while installing.
As you've known, by default UWP apps will be installed in C:\Program Files\WindowsApps. you can the default install location in Settings → System → Storage → Change where new content is saved.
You can choose one drive from the drop-down menu under "New apps will save to" and then click Apply. A new folder called "WindowsApps" will be created in the drive you've chosen. And any new UWP app will be be installed in this folder. Please note Windows 10 will only install new apps to the currently selected location. Existing apps do not get moved to the new location.
If you want to change the install location for a single app, you’ll need to head to Settings → Apps & Features then click the Move button.
However, this is only available after you have installed the app and it can only move the app to another drive. There is no way to specify the install location to some other folder like C:\MyApp\ etc.
This is a bit of an XY question so this answer may not be clearly related to the asked question.
Knowing the location that a UWP app package does not help in the least. It's fine for exploring the system as a developer, but it's nigh useless for a released app. Instead you need another way to launch your app.
UWP offers a handful of ways to start your app:
Use a protocol (i.e. a custom scheme in a URL)
Use an alias (i.e. an alternate command-line program name)
Use API (IApplicationActivationManager::ActivateApplication)
The first two of these require modifications to your AppxManifest. Since InstallShield doesn't put this front and center, it offers alternate ways to populate these parts of the manifest. (The third instead requires modifications to the code that would invoke this app, so I won't discuss that further.)
Protocol
To populate a protocol handler from InstallShield, merely add the protocol handler to the registry. When building the AppxManifest, InstallShield will read this registration and translate it into the manifest's protocol entries.
Alias
To populate an AppExecutionAlias from InstallShield, merely an App Paths registry key for each relevant entry point. An App Paths registry key is installed to HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths, and you should use the following format for your alias:
HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\<alias.exe>
(Default) = <path\to\your\exe>
For simplicity, your path should probably use either property references ([ProgramFilesFolder]Company Name\Product Name\executable.exe) or component references ([$componentid] - typically executable.exe or NewComponent23). When building the AppxManifest, InstallShield will read this registration and translate it into the manifest's alias entries.
I'd need to have wpf app in a shared folder from where users could make a shortcut and run it having an opportunity to right click on the shortcut and run it also as a different user.
So, I'm wondering if I could copy all files from the bin/release folder if it could work. I did publish the app and installed it on another computer but it seems as there is no possibility to use a right click with the run as a different user. So, I did also copy bin/release files there and made a shortcut from the bin application file and the run as a different user seems as working from that shortcut on that machine. But, it might be not a right approach. The publishing and installing might not be an option further as well as it would need to go through TFS eventually where it would be copying files from a one environment to another.
I did implement it through TFS. The TFS is finally generating mainly the same files as in bin/Release when it's built via VS.
I have an issue installing two ClickOnce Windows applications on the same server. I have published one successfully. I have a requirement to install this same application on a different website in IIS. This is a copy of the existing application with slightly different functionality (not important). After I publish and try to install it, I get the following error:
Unable to install this application because an application with the
same identity is already installed. To install this application,
either modify the manifest version for this application or uninstall
the preexisting application.
I've tried changing the assemblyIdentity version number and name in the Properties -> app.Manifest, tried changing the Assembly name in the Project properties, tried clearing the manifest cache and none of these worked. I realize that this is the same application that I'm trying to install on two different websites on the same server, but what needs to be changed so that it will install correctly?
You need to change the Product Name of your application's deployment. This is the application name stored in the deployment manifest file. Making this name different between your 2 instances will allow you to install both of them at once. If setting this through Visual Studio, this is under the Options button on the Publish tab of your project's properties window.
The NuGet web site has an excellent article for hosting your own NuGet feed. In our case we are an IT shop that needs to fully vet packages before making them available to our development staff so we would like to host our own feed which will provide "approved packages". One thing the article glosses over is how to pull down the nuget packages for hosting. So for example if we want to host EntityFramework 5.0.0 so our developers can use it how do we get the package without using NuGet as policy prevents NuGet accessing hosts past our firewall?
Assuming you're not completely cut off from nuget.org, you could use ProGet to host your network's feed. Since ProGet allows you to both create multiple feeds and also to connect to other NuGet feeds, you could create one feed, say "NuGet Cached", and then a "Developer" feed, and specify the same package storage location for both feeds. The trick would be to set up a connector to nuget.org on the "NuGet Cached" feed, then use the Pull Package feature to download the hosted NuGet packages to your local feed.
This way, developers would set up Visual Studio (or whatever tool they use to get the packages) to point to the "Developer" feed which only has the packages you have explicitly pulled down (since both feeds store packages in the same location). You could also add deny privileges to the "NuGet Cached" feed such that they can't connect to it at all.
Create a host server (sounds like you have, but if not it's installing and hosting a NuGet.Service).
Confirm it's working by visiting the host (should see a very simple dashboard saying the Nuget service number, etc)
open VisualStudio options, "Pakcage Manager"->"Package Sources"
Add your internal host here (probably something like http://internalsvr/nuget)
Then you should be able to install packages form that source locally. also, you can push things up there, or place the packages in the ~/packages/ directory and they will automatically be listed in the service.
You can probably try out http://www.myget.org or use any of the other software out there.