I'm using Visual Studio 2010 with the free version of Installshield. The application includes an ActiveX component which is called from Excel. The "Register for COM Interop" option is checked on the project Build properties page. When I run the install on an XP machine, the dll does not get registered. If I manually run the regasm /tlb: command, the application works.
Questions:
1. How to verify through the installshield log file that the registration was run?
2. What kind of error message would the log show if the registration failed?
2. Does installshield require that the dll be strong named? (It is not)
3. Are there other troubleshooting suggestions?
Thanks in advance,
Currie
Here's how I handle this situation:
1) Establish a clean OS.
2) Install your software.
3) use a registry compare utility such as InstallWatch Pro to snapshot the registry.
4) call Regasm.
5) capture the registry again and create a delta. Filter out unrelated changes.
6) Author those changes back into the InstallShield project. Rebuild and repeat the process to verify success.
So why is this broken? I usually find it as a result of a known behavior in Regasm.
When you set COM Interop = true you are telling InstallShield to call regasm /regfile and then scrape that data and author it into the installer during the build. But here's the catch:
(Emphasis added)
You can use the /regfile option to generate a .reg file that contains
the registry entries instead of making the changes directly to the
registry. You can update the registry on a computer by importing the
.reg file with the Registry Editor tool (Regedit.exe). Note that the
.reg file does not contain any registry updates that can be made by
user-defined register functions. Note that the /regfile option only
emits registry entries for managed classes. This option does not emit
entries for TypeLibIDs or InterfaceIDs.
Related
The way we use TFS is that in our development tool we export all classes of the project into one XML and manually upload that XML as the new version to our TFS project. However sometimes the export process includes classes that must not be in that export.
Can TFS validate the content of the upload and give a warning that the file contains illegal strings, such as "class this.that.shared.never_include_this_in_exports()"?
Can TFS validate file content and reject / give warning?
AFAIK, I do not think TFS supports validate file content feature when we upload it to the repo.
For TFS, whether it is a centralized TFVC or a distributed git, TFS only tracks and controls the file itself, and does not provide verification of the syntax in the file. This should be a function of our compiler. It should not be a function of a version control tool.
So we need to use other tools locally to verify whether there are any errors in our XML, or, as Daniel said, to verify whether the file is correct through CI.
We currently use TFS 2010 for controlling some of our .NET projects.
I'd like to know whether it's possible to provide some kind of versioning within TFS for a specific folder on a network share for example.
The idea being is to control release packages (zips) for every release we do. As this bit is done by some other person (not technical and he doesn't use Visual Studio or any tech tool), it'd be great to streamline the process of versioning the zip files for every release.
Technically speaking:
We've setup this folder \servername\releasezips and every time I drop a file named release.zip, it would automatically commit (push) this file to the TFS server (no comments needed) and furthermore, once the file contents change (meaning that someone dropped another version of the file in there), the system would again push the file to TFS, but with a following version.
Is this possible somehow? I've seen somewhere that I could programatically have some extra control over TFS, using REST API.
Thanks in advance!
Thanks for your tips, Daniel and PatrickLu-MSFT.
As I said, I did want something straighforward, some kind of control similar to what box.com provides, where you associate a local folder on your machine with the cloud. So, once you drop files in the local folder, the small box client synchronizes it along with the cloud. If access the box.com, I can see the different versions of that specific file.
So what I did was, I've created a small .NET app to monitor the folder and any new files dropped in there would get checked in to our TFS server, by using the tf command line (of course ignoring work items or comments).
So, progamatically within the .NET app, it builds up the tf required commands for processing and versioning the recently dropped files and therefore, executes them.
By the way, I could have used the Team Foundation API in order to do the same job, but it would demand way more effort.
Cheers
According to your description, you want to commit/check in files during the build/release pipeline.
It's not a recommend way to check-in generated build files and modify source code during a build pipeline. If you really want to do this, you could edit the build workspace files and use tf commands in custom activity and call the powershell eq:
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 1x.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Another way is installing TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for more details: PowerShell and TFS: The Basics and Beyond
For version the dropped files, you could take a look this similar question: TFS Build Copy to Versioned Folder
Basically, you have to customize build definition with custom activity and based on build.buildnumber variable to generate/create .zip file.
We are using TFS on Visual Studio 2013. When our developers Get Latest Version (GLV) and there is a new db script file received, it is stored under a specific folder, to be run using our custom update app.
What I want is that upon doing a GLV, they get a notification (in Visual Studio) that there are new scripts to run to update the db (generically speaking, that a new file has been added under a certain path).
Is there a way to achieve this with TFS?
It will not give you exactly what you want, but you can use built in TFS alerts to notify you or the team when a file is checkedin under a folder with a specific name/specified path/file extension.
You could write a visual studio extension, to be triggered on Get Latest, which would check a certain path within source control, you would have to roll this to all of your developers and would either have to store the lookup paths centrally or redeploy the app if the look up paths changed.
Alternatively you could add a bat / powershell script to your source control. within this script you could do the get latest and also run any scripts that you would like to run. you would then get the developers to get the latest against this script and then run it, which would get the rest of the files and would also run the db scripts.
If I understand correctly, you want your users to be running their locally built solutions against the latest database version to keep everyone in sync. Why not just use the usual workflow to procure 'notifications' in the form of build output?
I've dealt with this in the past, and the best solution I've come up with is to write a custom MSBuild target for 'BeforeBuild' into each of the projects that rely on the database being updated. The MSBuild target checks the version of the database installed (You would have to come up with a means for doing so, it can be tricky!).
If the currently deployed database does not match the version in the scripts you have just synced to, a build event could be raised. When the versions match the target would output a success message (or maybe nothing at all), and if the versions do not match the target would issue a build Warning or build Error depending on the severity of change observed (it might depend for you insofar as Major/Minor version variance is considered).
We've finally managed to do the internal housework that should theoretically allow us to start using SVN as our Version Control system.
I've setup the latest version (3.3) of Collabnet Subversion Edge on a server and as far as I can tell it's happily pointed where we want it to be. Getting the Active Directory authentication is different issue)
I've created a new Repository (Timesheets) in the Admin Console with the default "Trunk" "Branch" and Tag" folder.
So I go into Delphi, connect to the repository and store my credentials. I can see the folders, which are empty. Exit the dialog and open the Project I want to add to the system.
I right click on the Timesheets.exe in the Project Manager screen, and choose Add to Version Control. It lists the files, and excludes a couple (fair enough). I browse to the VCS URL and select the "Trunk" folder. Add a comment, and click Import.
Boom
Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request...
followed by
'G:\Delphi\Timesheets' is not a working copy
Which it isn't - ti the first load into the VCS, which I'll then check out to create a Working Copy...
Any pointers?
Looks like the problem was an issue between Delphi XE2 and Subversion Edge 3.3.
Switching to Tortoise SVN allows us to add projects to the repository.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information