All,
I have a WCF Service I inherited from someone else.
When I make a Build either Debug or Release, the binaries go in the same folder.
I was under the impression that Visual Studio 2010 always has two folders, Debug and Release and depending on the type of the build the binaries go to the appropriate folder.
Any ideas?
Rgds,
MK
Look at the Build tab of the project's Properties. There you'll see the Output path, which might be set to the same folder for both Debug and Release Configuration (selectable through the drop-down on the top of the page).
Related
I've looked over several suggestions for getting SlowCheetah transforms to work with Visual Studio Online's build system, but nothing seems definitive, especially for the Visual Studio 2015 world.
I have a web project with both build configurations and publish profiles in place. If I'm using the one-click publish, everything works as expected; first the build config transform fires, then the publish profile config transform. However, on VSO, only the web.config is transformed, and then only for the build configuration.
The goal would be to provide the build definition on VSO with the build configuration and publish profile to use (which I know can be provided via MSBuild) and trigger the transforms to work as appropriate. I'm using the new VSO build definitions that are done online through the web interface (not the XAML ones), and the good news is this has an option to restore NuGet packages automatically (which has been one of the issues in the past). It looks like other MSBuild steps could also be added, so maybe there's a way to trigger the process after the build or something.
Has anyone gotten this to work properly? Thanks.
I did a quick test on this but didn't see any issue.
The screenshot for my project:
And the screenshot for my build definition:
After the web project is published with these settings, I can get the "Web.config" and "XMLFile1.xml" transformed with the "edd" profile and "XMLFile2.xml" transformed with build configuration.
I'm developing a Visual Basic application using Visual Studio. My application worked fine with command line arguments until I compiled a "Publish" the first time. Now if I try to run the executable file generated in the debug folder I get a System.IndexOutOfRangeException thrown. If I try to run it inside Visual Studio I get this warning:
The current project settings specify that the project will be debugged with specific security permissions. In this mode, command line arguments will not be passed to the executable. Do you want to continue debugging anyway?
And then the code run without errors, but it does not create a new .exe file in the debug folder.
What have happened? How can I fix this problem? My code worked just fine until I tried to "publish" it. I haven't changed a single line.
The "Publish" feature in Visual Studio uses ClickOnce deployment technology. There's a pretty good overview of ClickOnce, and how it differs from MSI deployment, at https://msdn.microsoft.com/en-us/library/142dbbz4(v=vs.90).aspx.
The MSDN topic "How to: Retrieve Query String Information in a ClickOnce Application" at https://msdn.microsoft.com/en-us/library/ms172242(v=vs.90).aspx confirms that "It is not possible to pass command-line arguments to a ClickOnce application. If you want to supply arguments to the application, you must deploy it over the Web and supply query string parameters in the URL."
You can create still create File Associations for a ClickOnce application, but it requires specific configuration steps as well as modified code. The following blog posting walks you through this:
http://blogs.msdn.com/b/mwade/archive/2008/01/30/how-to-add-file-associations-to-a-clickonce-application.aspx
Overall, unless you have a specific need to use ClickOnce, I would suggest sticking with XCopy or MSI deployment.
I've got a solution that builds locally on my developer box, and I've tried it using remote desktop on my TFS build server, which is server, controller, and agent. What is baffling is that when I queue a build, it fails, with this message in the log file.
Considered "..\..\..\..\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.Coverage.Analysis.dll", but it didn't exist.
Part of what is so confusing is that If I navigate to that location, I can see the file that I need.
In further testing, I went to the build source folder and loaded the solution there. It shows that it can't located the reference. If I just remove the reference, and re add the exact reference again, it builds.
If you have a better title or want further clarification just ask or make suggestions.
I'm setting up a CI with TeamCity 8 (v8.1.4).
I finally managed to setup TFS integration - ie checkout from TFS.
I used the super easy Auto Detect Build Steps [thank you JetBrains for that] to determine the Build Steps necessary.
I used the Get missing NuGet packages step, which works as expected.
Then I have a Visual Studio Solution build step, that seems to build great, just until the point where it wants to build the Unit Test and Integration Test projects, which both use Microsoft Fakes.
Here I can see that TeamCity tries to search everywhere for the [AssemblyNameUnderTest].Fakes.dll - where [AssemblyNameUnderTest] is whatever dll that is tested.
I haven't included that dll to my project nor in TFS, since I thought that it would be regenerated each and every time I change something to the original AssemblyNameUnderTest (ClassLibrary) Project.
Should I include the [AssemblyNameUnderTest].Fakes.dlls to the project and TFS or am I right that they are regenerated ?
And if I'm right with the regeneration, then why TeamCity can't find it ?
Thanks in advance,
Michael
Ah, so I found the answer to one of my questions: http://hamidshahid.blogspot.be/2012/11/microsoft-fakes-framework.html
The files in the "Fakes" folder are only generated at the time of
adding the fakes assembly. They are added to the solution and should
be checked into source control.
The "FakesAssemblies" folder and all the files in it are generated
whenever the project is compiled. This is important because if you are
adding fakes for assembly for a changing component, the generation of
FakesAssemblies will ensure that all changes are reflected in the
generated assembly.
So I did that - ie it is the default behaviour.
Above that my .fakes files have the "Fakes" build action, but it still isn't working for TeamCity.
Also, TeamCity uses the MSBuild.EXE from "C:\Program Files (x86)\MSBuild\12.0\Bin" for the build.
Anyone a bright idea ?
To fix the build, I removed the Fakes stuff and implemented Moq mocks.
Seems to give you more control of what exactly happens.
I have an WCF project that if i use the Visual Studio option "Publish" gets published fine.
But if I use the MSBuild parameter DeployOnBuild it does not get published correctly. I'm getting an "Could not load type" error, and all of de dlls are there.
I using the MSBuild in a Build Definition in order to have a Continuous Integration Build.
The build parameters I'm using are:
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://host/msdeployagentservice
/p:username=#####
/p:password=****
My main problem with this scenario is that the build targets are the same, and the build definition actualy publishes the files, but somehow they are not the same.
Any insights ???
I dont like to answer my on question, but since it may help someone else is the cause of the problem.
One of the projects had a post-build command to copy the resulting
dll to another project specific directory (its not a reference
because it using dependency injection in runtime).
The dlls did not get checked in to TFS because they are not checkout automaticaly
The
Continuous Integration Build fetches the sources from TFS and the dlls are out of sync
The solution was to checkout the dlls before the build so that the checkin updates them