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.
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.)
Would there be a purpose of Azure Releases if I'm just building a WPF application?
In Azure Builds I can just use a Copy task to copy the output files to a drop location, right?
What would I do with Azure Releases when I have a WPF application?
Indeed, we could just use a Copy task to copy the output files to a drop location when we build/deploy the WPF application.
However, if we have to deploy the WPF application to multiple stages/machines, in this case, we may need add one more copy task to copy the output files. In addition, if the situation of each stages/machines is different, we may not be able to use only the copy task to complete the deployment. Now, we could use the Azure Release with multiple stages, like Dev, Test, Product and so on. one stage corresponds to an environment or machine, and each environment or machine can be set individually.
On the other hand, if we use a copy task to copy the output files to deploy the WPF application, WPF application will be deployed to the target machine every time when we enable CI. Obviously, not every modification we want to deploy to the target machine. So, we need a release pipeline to separate our build and deploy.
Hope this helps.
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)
I am aware for Enterprise Architect and version control (using Subversion), projects where each user possesses their own project (.EAP) file, each user must have a local working copy checked out.
In a centralized DBMS repository which allows all users to work on the same .EAP project file rather than having their own, is it a better practice to consolidate to a working copy folder shared amongst all users? Or does each user need to maintain their own working copy similar to a non-DBMS team environment?
I hope you choose another technology then .eap (which is atually MS Access) as underlying centralized repository.
But that set aside, the version control part stays the same. Each user has its own local working copy folder. EA works with exclusive checkouts, regardless of having a central database, or distributed .eap files. So having a shared working folder would not work very well for that aspect.
What we do to make it a bit manageable is to tell users to map their working folder copy to a place in "home" folder (which in this case is mapped to the H:\ drive)
Each user then has H:\SVN\Enterprise Architect\ as their working folder, but under the hood that gets registered as \\servername\username\Documents\SVN\Enterprise Architect\ making each working folder unique to the SVN server.
PS. In my case this was for TFS, but I'm pretty sure the same principles apply for SVN.
I've run over only a few examples of how to do this and they didn't work for me. Mainly since i've only used an ant script to auto build jar files threw jenkins. Now though i need to build those files in jenkins then upload them to a 3rd party file site like sourceforge. This is both to save hard drive space on the server, since i don't own it, and to allow external downloads. Any help is welcome but no comments on the fact i don't know to much about ant scripts.
Also something related by a bit separate.The jar file i'm building depends on a another jar file with its own version. i also want to make a new folder each time it uploads with a different dependency version. This way the users that download this file can easily understand the main jar version it goes with while allowing me to upload 20+ sub builds.
There are several ways to upload files, so there are several kind of ant tasks to do the job.
For instance, if you want to upload to sourceforge, you can use the Ant task scp. But it seems also possible to upload there via FTP: so here is the task ftp.
Maybe you find some other service which requires you to upload via HTTP: ant-contrib have the post task.
I used to do publications as part of my ANT build logic, creating a special "publish" target that issued the scp or ftp command.Now I'm more inclined to leverage one of the publish over plugins for Jenkins.
The main reason for this shift is the management of access credentials. Using the ANT based approach I was forced to run my build on a Jenkins slave that was pre-configured with the correct SSH key to talk to the remote server. The Jenkins plugin manages private keys centrally and ensures all slaves are properly configured.
Finally if your build has dependencies on 3rd party jars, use a dependency manager like ivy to download them and include them in your project. It then becomes trivial to include their upload as part of your publish step.