I'm trying to make a setup program for an ASP.NET web site. I need to make sure the target machine has sqlxml installed.
I must verify the target machine has the software installed, and if not, launch a .msi file either before or after the main installation.
I'm a complete newbie with setup projects, so maybe this is obvious, but after several hours browsing the web I haven't found a satisfactory solution. I've been reading about WiX, etc. but I'm looking (if possible) for a simple solution.
Thank you both!
I understand an installer can't run another one. I was thinking in a functionality similar to Prerequisites (in project properties). There I can check a component and it will be automatically installed if it isn't. I don't need to do anything else. But, the most important thing for me is that the installation won't run if it's not needed.
I also tried the .msm solution, but I couldn't find any. Maybe I can make one myself? I haven't tried it yet though.
Unfortunately, you can't run one installer from another, since only one can be running at a time. You need to chain them together and run one after the other. Google "msi chaining". This is often the reason why products like Visual Studio use an external setup.exe which then runs the installers one after the other.
Looks like you need to 'chain' the installs http://objectmix.com/xml-soap/84668-installing-sqlxml-net-app.html
You can get the redist here http://www.microsoft.com/downloads/details.aspx?FamilyID=51D4A154-8E23-47D2-A033-764259CFB53B&displaylang=en
CAn you add this as a pre-req for your install?
What are you using to build the create the install?
Edit:
I had a look to see how you can check of the SQLXML is installed and come across this:
http://www.tech-archive.net/Archive/SQL-Server/microsoft.public.sqlserver.xml/2005-04/msg00110.html
The system I am on just now has the following key HKEY_CLASSES_ROOT \ SQLXMLX (note the X at the end), so you might need to do a bit more investigation in to what the actual key is.
I'm not familer with Visual Studio install authoring but if you can add an entry to the AppSearch and RegLocator tables you should be able to check for the existance of the registry key when the install starts. See here
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
The Reglocator table gives you the option to set a property with a value from the registry if found. You can then use this in the condition on a custom action.
A lot to put together, but I hope it move you in the right direction.
Brent's answer is correct. I would just add that, sometimes, you can find a "merge module" for the bits you depend on. That's a .msm file. You can certainly include 1 or more of those in your .msi file. I have no idea whether a merge module is available for SQLXML. Sorry.
Related
When I bundle a script like so:
bundles.Add(new ScriptBundle("~/bundles/Product/Details").Include(
"~/Scripts/external/XXXXConfig-{version}.js",
"~/Scripts/external/Views/Product/ProductFavorite-{version}.js"));
My expectation is that if there were two files in that directory:
XXXXConfig-1.0.0.js
XXXXConfig-1.0.1.js
That it would only include the latest version, i.e., XXXXConfig-1.0.1.js. Instead it is bundling BOTH together, which causes the system to fail spectacularly.
My expectation comes from here, and other sources. Is this expectation wrong? In any case, is there some way to make it so that it ONLY includes the latest version?
Yes, your expectation is incorrect. The {version} wildcard is used as a placeholder for any version, not the latest. It allows it to update your NuGet package without having to change your bundling code every time.
The only smart thing that the {version} wildcard does is that it select the file with min (if it exists) for release and with no min for debug. Other than that, it's just a wildcard like any other.
I'm not aware of any built-in feature that selects the latest release for you. You'll have to program it by yourself if you want that. You can search to see if someone has already done such a thing. But I wonder why you want more than one version to exist in your folder.
Edit: To elaborate on the min feature as your requested, I think the MSDN that you linked to described well, but here is an example:
Let say your folder has two files SEMSConfig-1.0.0.js and SEMSConfig-1.0.0.min.js. When you run your project in debug mode, the file SEMSConfig-1.0.0.js will be used. When you run your project in release mode (or publish it), the file SEMSConfig-1.0.0.min.js will be used.
I've been asked to build a website with Plone. I would also like to use git version control for this project. Ideally, I would have all the work I do stored in one directory -- my project directory -- which will also make version control simple. Can anyone point me to a resource that explains how to do this?
We keep our company project skeleton at https://github.com/niteoweb/niteoweb.skel.plone.
It has some of our internal specifics, but should be usable. At least as a point of reference.
I've been trying to wrap my head around module development for DotNetNuke for the past day and I keep running into roadblocks. Prior to this, being the *NIX/OSX grognard that I am, I have managed to create a Skin and a few Widgets "The Hard Way" by creating the manifest file myself with a python script, coding everything in Textmate and using a Makefile to create the packages anytime I update it, then installing it onto a remote development site on some shared hosting. However, I want to try things the "DotNetNuke way", so I've been looking around for instructions now that I've got a Windows VM up and running.
From what I've found, this is what you're actually supposed to do:
Create a local dotnetnuke website.
When the dotnetnuke website has been created, go to Host -> Extensions -> Create Extension
Select Module and fill out all the forms.
Open up the website in Visual Studio.
Find your module in the <site>/DesktopModules and start hacking away at it
When you want to redistribute your package, go to Host -> Extensions -> Edit Module -> Create Package.
There are a couple of problems with this, however. I get as far as step 5, and for some reason I can't seem to find my module in DesktopModules. I have tried looking elsewhere in the directory tree for my test module and I can't find it anywhere. In addition, when I try editing a package, I can't see any "Create Package" button.
Any ideas where I'm going wrong? I'm using the absolute latest DotNetNuke as of this writing (5.6.0), by the way.
Update: Okay, feeling a little foolish I first have to create the module in Visual Studio, then create the module in the website and attach it to the manifest of my module. However, when I do this, my site blows up because it seems to assume that I'm using a company name of "YourCompany". Fine. I revert, delete the module and try again but creating my module with a namespace of my company name doesn't seem to change any "YourCompany" names, they're still all over the created files. What in the heck is going on here?
You need to do a search and replace in the entire project as well as the settings in the Projects settings. Also here is a link that may help link
Have a look in the project/solution properties under application make sure root namespace is not YourCompany
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.