i am new to installsheild deployment, i was tried many times, create custom action type--> New Powershell --Installed with Product.
then i specficed custom action to powershell script path- as ---Test.ps1.(browsing buttion)
this (Test.ps1) powershell script has path of my wsp.
like ----> Add-SPSolution "C:\Program Files (x86)\My Company Name\My Product Name\WorkflowProject1.wsp"
then build and run the setup. but my wsp is not deployed.
i reset my iis for every installation---whenever i run my installsheild setup.exe of wsp.
can any one explain---how to deploy wsp in instllsheild 2013.
I think you may have left out a step. You need to specify the "Sequence" in which your CA needs to run; and where in that sequence. Look farther down in the CA window on the right. It is safer to use the 'Custom Action Wizard' (first entry in the drop-down list) instead of the way you did it. That way you are reminded of all the things needed.
Related
I have a home machine and office machine I use to publish websites using Visual Studio 2013. If I make a change from the same machine, and re-publish, just the changes are published, not all files.
However, when using my clone machine at the office, even if I do a get latest, make one small change, and re-publish, all files are published, not just the ones that changed, and not just the ones that have been recompiled. ALL dll files, even third party dlls that have not changed or have been recompiled with a new date, are republished. Same thing happens if my cohort publishes a small change on his machine after I did the last publish. Not a problem if publishing twice from the same machine as then only the changed files are published.
Is there anyway to prevent complete republishing just because a different machine is used to publish than the one used for the last publish? Thanks.
This seems to make "Determining Changes" a lot slower, but for .Net 4.5 [and
up(?)], use this info from:
https://msdn.microsoft.com/en-us/library/ee942158:
To configure Web Deploy to use checksums instead of dates to determine
which files need to be copied to the server, add the following element
to the .pubxml file (Publish Settings):
<MSDeployUseChecksum>true</MSDeployUseChecksum>
Like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSDeployUseChecksum>true</MSDeployUseChecksum>
<!— other settings omitted to keep the example short -->
<PublishDatabaseSettings>
<!— this section omitted to keep the example short -->
</PublishDatabaseSettings>
</PropertyGroup>
</Project>
First of all, I do not understand the behavior of MSBuild+VS2013 and the publishing feature completely as I just started to use the publishing feature myself. I'm looking for a way to speed up publishing via FTP web deploy in VS2013. (I'm not using TFS for a get latest though.)
I would say this is partially explained in a different context at this SO question. The MSBuild process. Timestamps of certain files are being compared and then could indicate MSBuild/VS2013 whether a target (build output) is up-to-date or not. Then files that are not up-to-date are being recompiled.
As you all work on different machines, timestamps are likely to be different quite soon.
To find out what is actually going on during builds/publishes, set build output verbosity to detailed or diagnostic, for a moment:
VS2013 menu - Tools - Options... - Project and solutions - Build and run - output verbosity - set to -> detailed or diagnostic. Run the build, and see the Output panel/tab in VS2013. Select "show output from: Build" to see results if not already visible. Don't forget to set it to the original setting after checking the build details, as it could slow the build down a bit.
But why even unchanged third party dll's are being republished? Possibly because these dll's ARE actually overwritten during a build. You might have the assembly reference property "Copy local" set to true to get your website running without any manual uploads to be done for this. Or you are using a commandline copy command with the overwrite parameter explicitly set to true during project's post build event (like 'copy /y ...' or 'xcopy /y ...'). Then the timestamp of the file that is to be published is overwritten for sure, see in
the "obj\Release\Package\PackageTmp" folder (or for example: "\Debug" instead of "\Release" if Debug build is set for the selected publish profile.)
Furthermore, VS2013 as default does NOT check timestamp differences on the targeted webserver if you are using FTP publishing, at least that is my experience. As for the other publishing options like a web deploy I don't know yet. But the differences you experience seem normal behavior to me, as you run builds on different machines and publishing files from different machines as well. So timestamps are likely to be different... which, again, indicates 'changed' files to be published.
As I'm curious how this question should be solved, I was looking for this in the first place:
Maybe a TFS build server is an option for you, configured with a rolling build. But I read on a specific SO (sorry, can't add more links at this moment as I've just registered) that is suggesting to do clean builds to prevent new problems. And that will force full publishing again as files are all being changed by the clean build... so that won't work I think.
As an answer, you might want to use these FAQ answers on MSDN for web deployments. See the questions:
"Can I exclude specific files or folders from deployment?" .NET 4.0/4.5 and/or
"How to make Web Deploy use file checksums instead of dates to
determine which files were changed?" .NET 4.5 only!
The first option is to exclude files.
The second option is to use a checksum to compare files instead of timestamps, but that could be somewhat slowing the build(?) process, as the FAQ says. Note the first few lines on that FAQ pages, on how you can edit your publishing profile to apply one or both of these elements!
Also it is an option to put the thirdparty dll's in a different project which you then could only include that project in the deploy for a certain solution configuration (VS2013 menu - Build - Configuration Manager, see the checkboxes in the 'deploy' column there for every project. Though I'm not sure if this is part of the VS2013 'publish' feature as a web deployment, because this deploy column checkboxes are greyed out for my solution projects for some reason I don't understand yet... so I can't test it to verify this option.)
Though it sounds logic, don't forget to create backups/copies/screenshots first before you change any settings or publishing profiles, and then change the same settings/configurable files on the other machines you and your colleagues work at.
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
Hello everyone and good day!
Question: I had create a Basic InstallShield Project in my MSVC2010, added some files and primary outputs and press build. Project compiled normally: there was created MSI, setup.exe, setup.ini and (WTF?!) local directory structure of files, which I'm trying to install (for example, "Program Files\My Company\app.exe, ..." files was copied there). I throught that this is not needed folder, so copied my setup files (MSI, setup.exe, setup.ini) to another folder and start installation. When process of installation come on to copy state, installer gave me the error, that no required files (app.exe,...) was found.
Does anybody solve this problem? I think this is the simple one.
Thanks!
You can achieve this by making some changes to the properties in solution explorer. This is so simple as you can compress all in single .exe file. Follow the given below step:
Right Click On Entire solution and Choose Properties as given below
Second step as you can see the dialog box. click on configuration Properties
Third Step
Last step
This is finest and easiest way to achieve the required task.
Answer was found by myself, but thank you all any way...
To create a self-extracted install file you need to open "Releases" tab in your InstallShield Basic project and right click on configuration click "Release WIzard...".
All what I need is at this figure:
Select Compressed from Compression option in properties view.
Simple use the "single image" build. Not cd nor dvd
I'm looking for a clean, and repeatable, solution to deploying custom site columns and content types to MOSS using a WSP. I've currently split up my product into two Visual Studio solutions. The first contains the code itself where the second will contain the XML files required to describe the site columns and content types.
We use Vsewss for this, there is also a tool WSP Builder. Both of these tools will help you build the xml and wsp files.
We then create setup projects that build an MSI to deploy these files and run the activation.
You might consider merging the code and the other files into one VS solution. This is often easier to manage and will allow you to leverage either VseWss, WSP Builder, PowerShell or .bat files to aid with building and deploying the .WSP file.
I'm using WSPBuilder and it is being very helpful. However, it was being hard to understand the strength of WSPBuilder because of missing manual. I've to create a solution file to deploy "Return of SmartPart" (.wsp file), "Application Template Core" (.wsp file) and also "AJAX Extensions" (.dll files). So, I won't have to edit the web.config to mark them safe controls. Please, suggest HOW?
Quick answer:
C:\Program Files\WSPBuilder\WSPBuilder.exe.config
(or where ever you've installed it)
add key="BuildSafeControls" value=""
Long answer:
WSPBuilder is great for when you want to do a quick deployment via Visual Studio to your SharePoint installation. I have found that that it gets harder to configure when you need to deploy CAS policies but I'm sure they will do work in this area for future versions.
WSPBuilder in your scenario can automatically build and deploy the safecontrol entries that need to go into your site. Good thing about WSP's are that once you retract a solution, it will also go back and remove the safecontrol entries so you don't need a tidy up job.
Regarding different projects, if you need to install third party wsps, then WSPBuilder hasn't been designed for that purpose, I suggest a simple batch file with some stsadm commands. If some of these solutions are your own code, you should divide each into a different VS project and build their WSP's seperately. You may even need to divide them into different .sln (solution files) but I've not tried this way myself so couldn't say for sure.
Personally, I would only use use WspBuilder to build deployment packages that need to be deployed to live environments if I can be sure its not adding extra bits that may become a problem. Therefore you'll need to think about WSPBuilder wsp's are good enough for you.
Recently I came accross an issue with CAS policies and decided to make my WSP's manually. Under the hood, WSP files are CAB files, you can just create a CAB file and rename its extention to .WSP. I would advise, creating a WSP, rename it to mysolution.cab. Open it and up and extract the files, and have a look to see whether its doing what you want. Key file to look at: manifest.xml.
As far as I know, you can't nest WSP files in other WSP files. You'll have to install those separately.
If you want to install DLLs (other than the one that's built as part of your WSPBuilder project), create a folder in the project called GAC and put them there. All DLLs in that folder will be installed to the GAC when the WSP is installed.
To install a WSP package, you'll need to run:
stsadm -o addsolution -filename MyFeature.wsp
You can then deploy it from SP Central Administration.
You can also create a WSP file manually without WSPBuilder - it's a CAB archive and you can create a WSP file using the makecab.exe utility that comes with Windows and an additional description file that lists the files that should end up in the WSP file.