When I deploy applications to our BizTalk server, we deploy to a test machine, add all the necessary resources and then export an MSI that we import on our production servers (we have two). The other day I noticed that there are dozens of folders on our production servers that appear to be copies of each developer's source code location.
For example:
C:\Development\MyProject1
C:\Projects\SomeProject
C:\Users\Ryan\My Documents\Visual Studio Projects\Another Project
Many others
They're all projects we've deployed to BizTalk and the folders don't contain source code, just the "Deployment" folder of each BizTalk project with DLL files in it. However, I thought the MSI packages were adding the DLL files to the GAC, or at the very least, were putting them in the MSI install target folder (all MSI files are installed to "C:\Biztalk\ProjectName").
Can somebody shed some light here? Are these extra copies safe to delete, and will that stop my BizTalk applications in their tracks?
(I just reread your question and see that my answer may need some more context. Before you deploy the next time, have the developers follow the steps below so that you won't end up with the folders you mentioned in your question.)
You have control over the installation folder - you just need to change your resources' destination using BizTalk Administrator. You can also control installation in the GAC.
Use the following steps to modify the installation folder (things get installed in the folder that the user specifies when running the MSI):
In BizTalk Administrator, under your Application's Resources folder, review the values under the Source and Destination Location columns - you'll see folders and drive letters that exist on your system.
For each item in the list, right-click and select Modify
Change the Destination location - the path part of the location - to **%BTAD\_InstallDir%** (include the % symbols and separate the last % from the file name (probably a DLL) with a back-slash character ( \ ). So, it might look similar to this when you are finished: **%BTAD\_InstallDir%**\MyStuff.DLL
Export your application
Run the MSI on your target systems - things get installed in the folder that the user specifies when running the MSI
This is the essence of the solution - I coincidentally wrote a brief blog post about this last month.
I wouldn't delete them until you did a redeployment. BizTalk is remembering the location the resource was initially added to the resource meta data source. For purpose of generating an MSI you should add the resources from where you want them to reside on the production server.
Related
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
I have an app that I am moving to another server. It is complaining that it is missing TABCTL32.OCX. I have located this file on another server and I want to copy and paste it across.
I have discovered that there is also a file called TABCTL32.DEP on the server I am moving from. Do I have to copy both files across or is the dependency file optional?
I have tried it with an without the DEP. The app works in both cases. It is a production server so I want to be sure.
Those .DEP (depdendency) files are instructions about a library meant to be used by packaging tools. These files have no run-time significance, containing only development metadata. They are text files.
They contain the preferred ("designed") location to install the library, sub-dependencies of the library including optional localization "satellite" resource DLLs, version information, etc.
See articles such as INFO: How Setup Wizard and PDW Use Dependency Files.
This is information a packager should use along with other "rules databases" such as VB6DEP.ini. Programmers are also supposed to create them if they expect other developers to use their libraries.
If you are using an "impaired" 3rd party packaging technology that is ignorant of .DEP files it is up to you to read them and incorporate the information they contain in your build process. You are also responsible as a developer to keep your dev machine's .DEP files and VB6DEP.ini file up to date, since they often are not updated by Microsoft anymore.
You can't just copy files willy-nilly from one machine to another. Go find this program's installer and run it on the new machine.
A .dep file is a file used by the Visual Basic Setup Wizard to determine what dependencies your ocx file have. You can open the file with Windows Notepad to view the contents.
Unless you are using the Visual Basic Package and Deploy Wizard, you can ignore this file.
For more info, see INFO: How Setup Wizard and PDW Use Dependency Files
We are trying to adapt a build automation strategy for our ASP.NET web site (not a web project) in vs 2010 ultimate & tfs 2010.
Build definition makes the build and publishes the web site into folders like
<drop_folder>\<defn_name>\<defn_name>_<year><month><day>.<build no>\Release_PublishedWebsites
Now we try to delete particular files and folders from that folder. For instance the "images" or "files" folders, that we need to exclude before packaging. I know that if it were a web project, there exists a straightforward solution. We also tried to modify the build process template (xaml) file. There is a "DeleteDirectory" component but we couldn't figure out what to write to the Directory variable.
Thank you.
If you follow the XAML way, you would just have to feed the Directory argument of DeleteDirectory with the physical UNC path to the folder you 're trying to get rid of.Something along the lines of String.Format("{0}\\{1}\\{2}\\Release_PublishedWebsites", BuildDetail.DropLocation, BuildDetail.BuildNumber, Date.Now.Year)
should get you near to your target. Since the drop location of the build might be on a different machine, also ensure that the account conducting the build (by default = NetworkService) has the rights to delete folders on the target.
Context : Windows 7, VS 2010, Tortoise SVN , and VisualSVN (all up to date)
We have some problems with our web.config files and .csproj : in these files there is informations common to the whole project (like connection string, configuration element) and informations depending on the machine (mostly file path).
So the problem is, each time I commit my web.config, my colleague has to go back to his file and change the file paths.
Did you find any way to handle it ? I tried to remove these from source control but it's kind of a problem (each time someone add a file to the project we have to add it manually, or a configuration key).
Thanks
One way we've handled file paths in the web.config is through the use of symbolic links.
i.e. in the commited web.config have the files paths point to e.g. C:\website then on each developers machine run the following command:
mklink /d C:\Website c:\path\to\develper\specific\checkout
Thus no-one should need to re-edit the paths to point to their workspace.
We've not had problems with our .csproj files - they don't have machine specific config in them.
We did however have similar issues with app.config settings. Again solved by either having each developer store files in a set location or having a symbolic link from the set location to their location.
For connection strings, we've either got them all set to localhost or set them to localdatabase and have a host entry on each developers machine. This will only work if each developer connects to the same database name but on a different server. If you're connecting to the same database server but different databases, you'll need a different tactic.
If I use the publish feature in VS2008 (I think it's called ClickOnce install), and then install the published application in another computer, where are the files copied?
In other words: If I need an auxiliary file (a .txt file) in the same path of the assembly, where do I have to create it?
Thank you.
You should have specified the location when you published the application. Just note down that folder.
If you run the wizard again for the same project it should have remembered the location and the folder will be pre-filled on the form.
I've used this and I specified a location on my hard drive for the Publishing Folder Location. This folder contains the following files:
publish.htm
setup.exe
[application].application
It also contains a folder called Application Files which contains the files needed to build the installation - the exe, the manifest, other dlls and external resources.
I then copy the three files and the folder to the web location specified by the Installation Folder URL.
If you're talking about where the files get installed to then they're in:
C:\Documents and Settings\[user]\Local Settings\Apps\2.0\H165QZM1.QBE\0OAEZTRX.Y3N\[some truncated version of the exe name followed by a GUID]
Which isn't the most obvious place. I should also point out that the folders H165QZM1.QBE and 0OAEZTRX.Y3N will probably be different on different machines, but the only other folder under C:\Documents and Settings\[user]\Local Settings\Apps\2.0 is called Data so they should be easy to spot.
Is the application available offline or online only? My experience is online only and in that case I believe it installs into a temp directory. Can you include your auxiliary file as part of the application files? This may help as well it talks about including data files which can be of any type.
http://msdn.microsoft.com/en-us/library/d8saf4wy.aspx
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx