I have a Visual Studio 2010 solution that is set to build in Debug x86. Visual Studio therefore sets the output path to \bin\x86\Debug, which seems logical enough.
The solution contains about 50 projects; the start-up project is a WCF project.
When I do a build, I would expect all output dlls to go to \bin\x86\Debug, as that is what is set in the project settings. But weirdly, I see dlls being created in bin\x86\Debug and in \bin. Why would Visual Studio put any dll in \bin if the output path is not set to that directory? It seems that all dlls go to \bin\x86\Debug, and all dlls except for the start-up project go into \bin. Any idea why it would do that? (We have other solutions that don't use WCF, and they don't have this problem.)
The other annoyance is if I run the service from Visual Studio and then try to access my service in a web browser, by going to http://localhost:1240/MyService.svc, it doesn't work, because the start-up project dll is missing from /bin. I therefore have to manually copy this one dll from \bin\x86\Debug to \bin, so that all dlls are found and the service runs normally. (We could of course add a custom post-build step that does the copy, but you'd think there'd be a better way!)
To those of you working on WCF projects, do you leave the output path at \bin\x86\Debug? (Perhaps there is a way to configure the service, eg in the web.config or .svc file, so that it knows the binaries are in \bin\x86\Debug instead of \bin?) Or do you change the output path to \bin so that you can run your service straight from Visual Studio?
If you open the property page of you WCF Hosting project and goto tab Build, under the Output section of this tag there is a textbox that contains the location of the output binaries.
For a WCF project the binaries should go to bin directory irrespective of the build type (suc as Debug, Release). Make sure this value has been configured correctly.
The value needs to be configured for each build type\configuration.
If you need, for whatever reason, different outputs from different build configurations in different folders you could specify them like you did first and use a post build event command line that copies from your specified output folder to bin.
Like:
- untested code -
COPY/Y "$(OutDir)\*.*" "$(SolutionDir)$(ProjectName)\bin\"
- untested code -
Related
I'm in the process of updating an old solution from Visual Studio 2005 to Visual Studio 2015, and I'm trying to reproduce as much of our old kludgy behavior as we safely can to minimize the downstream effects. I'm currently running into an issue with the Website Property Pages and MSBuild.
The path here is mostly correct, except that we want the configuration used to be in the path as well. So a Debug build will go into E:\Projects\...\PrecompiledWeb\Debug\MyService and a Release build will go into E:\Projects\...\PrecompiledWeb\Release\MyService. Is this doable? Is there a variable I can insert to make that determination when building?
We're using msbuild against the containing solution file (via TeamCity if it matters, but I can replicate it without it).
Edit: I've found the Debug.AspNetCompiler.TargetPath and Release.AspNetCompiler.TargetPath paths in the solution, but if I change them to be separate, the Debug one overrides the Release one when I next open the dialog.
When MSBuild starts building the project, it takes one or several project files. This dialog takes it parameters from MSBuild project file (you can edit it either from Visual Studio, or simply in every text editor). The project should have the property, called $(Configuration). You can use it in your output variable:
<OutputPath>E:\Projects\...\PrecompiledWeb\$(Configuration)\MyService</OutputPath>
One thing you must aware of is that the property $(Configuration) must be declared before the $(OutputPath) property.
I added into Solution(contains 30projects) Wix Installer, which is supposed to pack web service folder. Among files i want to pack is BIN file with plenty of dlls. On local with Release mode it works fine, however if i run TFS 2013 build definition over solution i get these:
C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\filesToBeInstalled.wxs (97):
The system cannot find the file 'C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\..\..\..\ABC WS\bin\ABC.Components.DataAccess.Lib.Utils.dll'.
I asked my colleage who administrate server and he told me that BIN folder isn't created in 'expected' location.
Now i don't have access to server and colleage is unreacheable, is here rule where binaries for all project/within solution are stored?
Update:
Somehow we overlook BIN folder - 'as configured' is and was set in definition however files still couldn't be found - problem was in build order(weirdly in VS2010 was correct) setting dependency wix project on target project helped - problem was that wix project was builded before target one.
Team Build creates uses a MsBuild parameter to redirect the build output of projects. If you need your Wix Installer to package up content that has been redirected, your installer script must be aware of this redirection happening.
The output structure of team build looks like
Build Agent Root
+- Unique build folder
+- src <- This is where your Wix project is placed
+- bin <- This is where Team Build redirects the project outputs to.
+- Test <- This is where Test Results are stored
This allows Team Build to figure out which outputs to copy to the drop location with a lot more accuracy, but it breaks any scripts that have hardcoded (or relative) paths to build outputs.
There is hope though, you can use the $(OutDir) or $(OutputPath) parameter to find the location Team Build has been configured to drop your binaries. You can use the '$(BuildingInsideVisualStudio)'=='' and/or '$(TeamBuildConstants)'=='' to detect whether your Wix Script runs in Visual Studio or in Team Build.
That way you can define multiple source locations for your Wix packages or to set the base directory to a certain value and use that variable in your wix scripts.
Or if you simply want your team build to match your bin structure when running in visual studio, set the 'output location' parameter in your build definition to 'as configured' - see this link for details:
http://blog.stangroome.com/2014/02/10/override-the-tfs-team-build-outdir-property-in-tfs-2013/
When using DefaultTemplate from Visual Sturdio 2012 (and TFS 2012 server), the PDB files are included in build directory. I do not want them.
Is there a way not to generate those files during build process?
Or
How can I delete those files?
I found this thread about deletion but seems a bit strange (no delete activity?)
There also is this answer but does not involve XAML template.
Thanks in advance for your help.
PDB files hold debug information on your code and its not advised to disable them, they are valid output hence deployment shouldn't be messing with them.
You can disable their generation in Visual Studio project Properties> Build > Advanced > Debug Info = none.
If you absolutely want them gone then disable them for build specific configuration (relaese etc.)
The build server by default does whatever the Solution (sln) tells it to. That by default is to do a "Debug" build and that created the PDB's. You can tell the Build to do a "Release" build that will not by default create any PDB's...
Figure: Adding a Build Configuration
I would however recommend against it as the PDB's contain information that you need even in production systems. Consider for a moment that you have a DLL in production and the customer is encountering a problem. You get them to create an InteliTrace log so that you can debug it locally (or they let you debug on their environment) and suddenly you are trying to debug without Visual Studio understanding the relationship between the Executable and the Source Code. So no debug...
Since I was unable to find building option to disable PDB file generation, I delete them afterwards.
There is no easy way to delete files. I did:
use a FindMatchingFiles Activity with wildcard *.pdb, which returns
a full path to pdb files
use a Foreach loop
call a DotNet method in the loop for each file with the InvokeMethod Activity,
with target type System.IO.File and method being "Delete"
In the previous version (Visual Studio 2010)
When we build /release, it was not generating PDBs, the PDB files are created when we only build with /debug:full or /debug:pdbonly, we use /debug:pdbonly if we want to generate PDBs for a release build that we do not want to be debuggable.
This is not the case in Visual Studio 2012, I checked it and I found it generated PDBs in both, /debug and /release
There is no documentation for Visuals Studio 2012.
I've got a ClickOnce .NET 4 application deployed by Visual Studio 2010, via a UNC path. I open the .application file, change the startup location to use the HTTP address, sign, and close. The application then gives this error:
Application manifest does not accept specification of <compatibleFrameworks>.
How do I get MageUI.exe to include this needed element when I sign?
This is similar to Stack Overflow question Why does Mage.exe not generate a compatibleFrameworks attribute?.
I've tried opening MageUI from the location suggested, to no avail, and I'd really rather not have to use MSBuild. This is a simple application, and I'd much prefer Visual Studio's simple built-in deployment.
Also, in case anyone's wondering, I can't deploy via HTTP through Visual Studio, because that requires FrontPage extensions to be installed, among other reasons.
Try using the MageUI.exe version from the .NET 4 folder, which is in:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
By the way, you can set the publishing file location to the UNC share path and the installation URL to your HTTP address and THEN publish. It will put the files on the share, but the installation URL will be set. If that's all you're changing, that would be easier all the way around.
Also, just FYI, you can publish with FTP (publishing a file location is something like ftp://myserver/myfolder/) if you don't want (or can't) to install the FPSE.
I have WCF library project which I have recently done some minor refactoring on eg changing the namespace and changing it location on disk. I also removed the app.config, because I thought the app.config is used by whatever hosts the wcf service.
I have since noticed that I can no longer debug the library using the WcfSvcHost like I used to be able to do. The message I get from Visual Studio is:
'A project with an Output Type of Class Library cannot be started directly.
In order to debug this project, add ana executable project to this solution which references the library project. Set the executable as the startup orject.
I don't want to do as it says, because I didn't need to do this before. Please let me know how to restore the ability to debug it using the WcfSvcHost. On the Debug tab of the project settings, the Command line arguments is still set to: /client:"WcfTestClient.exe"
Not sure what else to try, thanks.
I have observed that changing the output path of the project cause this behavior. To re-enable the debugging using WCFSvcHost/WCFServiceClient leave the output path to default and it should work.
If you changed the project output path you can still run it, you just need to provide some extra parameters to WcfSvcHost like this (enter this in Command Line Arguments in project's debug settings):
/service:ServiceInterface.dll /config:application.config /client:"WcfTestClient.exe"
No need to enter the full path as it will be run from your new project output path
If you still get the 'A project with an Output Type of Class Library cannot be started directly' then you can try changing the start action to 'Start external program' and select the WcfSvcHost.exe in there
You need to build the project in Debug Mode in order to use WcfTestClient and WcfSvcHost
In Debug mode you don't need another project. The Wcf Service Library runs in WcfSvcHost
However if your solution has only Wcf Service Library you need the app.config to configure the endpoints and etc...