I wrote a "Hallo world" type Windows Forms application in C# to test authentication issues. I'm going to be running the eventual application from a server periodically, so I want to be sure I can get to the resources, and fix that before committing to the whole application.
So, in Visual Studio 2010, I choose Publish....
It says "Where?", and I specify a folder on a shared file system.
It says "How will your users install", and I say, "URL" or something like that.
It says "Where", and I give it a URL in the same shared file system, different folder.
All is right with the world....
Now, I install it on my server by double-clicking "setup" on the shared file system where I published the application.
Now, I find a shortcut in my start menu, all good.
Now, I want to set it up so SQL Server Agent executes it periodically (and tests authentication...) so, what is the URL I give it to execute? I've been trying everything, but not going so well. I don't understand the publish method much at all....
How can I fix this problem?
Look at the Start menu shortcut for your installed application and you'll see that it points to a "ClickOnce Application Reference" (.appref-ms) file buried deep within your user folder. You can start the application by executing that file.
Example:
Process.Start(#"C:\Users\Igby\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft\MyClickOnceApp.appref-ms");
I don't know anything about SQL Server Agent, but try giving it this path.
Related
I am facing an issue, I am writting a script to automatize some part in a project.
Basically, it builds a website: building the front end part, creates in IIS the application, virtual directory, application pool and then build the back end part.
But I have an error when I try to access it (here the error in the event viewer (and I don't have anything more)
event viewer error
(For info the folder "bin\ISSSupport" does not exist at this very moment, it is only created after the fix explained below)
To fix it I just need to execute IIS launcher in visual studio:
IIS launcher
I would like to know if there is a way doing this action with command line.
(Or even better if you know a solution to my first problem)
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.
I have created a small desktop application using .NET 4 for generating an authentication string. It runs fine on my Windows 7 computer, however when I deployed it to our QA guy on his Vista machine, it gave him an error saying he needed to install .NET 4... FAIR ENOUGH. We installed .NET 4, however the next error said that "Microsoft.Web.Infrastructure.dll" was missing from the GAC. Crap. So I poked around a bit and found this:
I then set Publish Status of Microsoft.Web.Infrastructure.dll to Include and published again. This time it gave him an error about "System.Web.Mvc"! So I knew I was on to something. So I went and did this:
However, now when he runs it it just says it can't download files required to run the application, and will not specify what they are!
How can I properly publish my Windows desktop application in such a way that will ensure the end user has the right files needed to run it?
Note: I think Razor and MVC are included because this windows desktop app project is dependent on some other projects in this solution that are using MVC. (Basically this desktop app is using some of the Models.)
Edit: Here is the end result (README was added by me not VS)
As it turned out, the second screen shot view with everything set to Include was the proper way and worked fine while the first screen shot caused missing DLL errors during install. It really was just an FTP upload user error that had the installer looking for a folder that was not there, which is why the second version did not work the first time.
I think you should be looking in the Prerequisites dialog from the Publish tab of the project Properties window, not the Application Files dialog. Not sure if this is an SP1 feature or not (I have SP1).
Image reply from Ryan (question poster):
I am curious about using an object db so thought i'd give Eloquera a go.
I am having problems getting it running unfortunately. (running in "desktop mode")
I have done these steps as directed:
1) Copy the following assemblies and a configuration file from the %ProgramFiles%\Eloquera folder into a project folder:
Eloquera.config
Eloquera.Client.dll
Eloquera.Common.dll
Eloquera.Server.exe
You can copy the reference files into a separate folder for your convenience.
2) Uninstall the Eloquera DB (sounds awful, but we have copies all files we will need) - (I never installed it)
3) Add Eloquera.config into your project via “Add an existing item…”, and set its "Copy to Output Directory" property to "Copy Always". Done
4) Add the project references to these files:
Eloquera.Client.dll yep
Eloquera.Server.exe yep
5) Rebuild your project and check that Debug\ and/or Release\ folders contain the following files along with your application:
Eloquera.config
Eloquera.Client.dll
Eloquera.Common.dll
Eloquera.Server.exe
It does
6) You may change a physical path to the database files in the Eloquera.config file by setting DatabasePath value:
DatabasePath="c:\dev\db" I did this also
The error i get is this:
The connection to the server (local) on the port 43962 cannot be established.
The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
Weirdly, changing ServerPort to something else in the config does not change this error.
Any ideas?
I think this mode is not supported.
You are meant to use Client / Server mode, which is a shame cause i was hoping i could use this desktop method to deploy into a shared host.
No dice.
You can download from Eloquera website desktop project that is already configured and working and can be used as a base.
Kohan,
Desktop mode is supported in Eloquera, otherwise my application would not work. :-) There is a good start-up project for the desktop application on the Eloquera web site, have a look at that.
I get this issue with VS2010 and 64 bit Windows 7 - if you are using the 32 bit dlls (as we are as our app needs to work on 32/64) then make sure your target build (in VS) is set to 32 bit rather than AnyCPU.
I still cannot get the Database browser working but the code is working now.
Also - obvious things like make sure your firewall is turned off etc. make sure you can telnet onto the port