I am very much new to the Continous Integration. Could anyone please let me know whether we could build a website using MSbuild?
You can build a Web Site project using the AspNetCompiler MSBuild task.
http://msdn.microsoft.com/en-us/library/ms164291.aspx
Your MSBuild file might look something like this:
<Project
xmlns = "http://schemas.microsoft.com/developer/msbuild/2003"
DefaultTargets = "PrecompileWeb">
<Target Name = "PrecompileWeb">
<AspNetCompiler
VirtualPath = "DeployTemp"
PhysicalPath = "C:\ccnet\myProject\WebSite"
TargetPath = "C:\ccnet\myProject\PreCompiled"
Force = "true"
Debug = "true"
Updateable = "true"/>
</Target>
</Project>
And then within your ccnet.config, you would add something like the following in the tasks block for your project:
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
<workingDirectory>C:\ccnet\myProject\</workingDirectory>
<projectFile>C:\ccnet\myProject\myproject.msbuild</projectFile>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
If you have an SLN file for the Web Site, then you can use the following command:
msbuild YourSolutionFile.sln
Yes, you can - even with a "website".
What you need to do is add the "Web Deployment Project" and set it up so it will grab all the files from the website, compile them, and using something like WiX, you can create an installer for the files to be able to easily deploy your web site and all its files needed to a customer's computer.
Marc
unfortunately, if you have chosen "Website" as the project type you cant. However, if you chose "Web Application" project type, you can use MSBUILD to build it. Once you have created the "web application" project, you can right click on it and select "Add Web Deployment Project" which will add a wdproj file to your solution and you can customize the settings in there.
You can provide this wdproj file to your ccnet config file for the project which can run this as per the schedule configured. i can probably give you teh appropriate nodes required to configure in cc.net config file by tomorrow once i am in the office
Related
The question is a follow up to this one: Generate Web.Debug config which could be debugged](Generate Web.Debug.config which could be debugged)
I have defined a transformation for web.debug.config. During compilation I see the following:
Transformed Web.config using C:\data\Main\WebRole\Web.Debug.config into
C:\data\Main\obj\obj\x64\Debug\WebRole.csproj\TransformWebConfig\ [...]
transformed\Web.config.
Checked Web.config in the specified location - it is correct (transformation succeeded)
But when I start the service in the azure emulator I get an alert that
Why does it happen? Looks that incorrect web.config is taken. Where should I specify the location of correct (transformed) file?
The key thing to realise with web.config Transforms (and is mentioned in the answer to your linked question) is that they are only part of the story.
When you build your sources, the transformed web.config file is built into the /obj/ folder, ready for deployment.
It is only the act of deploying your solution somewhere that puts the transformed config file into use - as noted in the docs:
When you deploy the Web application by using the selected build configuration and by using either a deployment package or one-click publish, the Web.config file is transformed according to your specifications.
How are you running the application after you build it? You need to publish or deploy it using one of the built in mechanisms that support web transforms to see those changes on your site.
If you are running the emulator against the original source files, they won't see the transformed web.config file - which is why typically the debug build doesn't have any transforms and you then turn off debugging with your Release build which is then deployed to production.
As you're trying to test this in the emulator you should be able to do the following:
In the Solution Explorer, ensure you've selected a file within the project that runs in the emulator.
From the Build menu, select "Publish [Project Name".
In the Publish Wizard, create a new "Profile" using the "Custom" publish target.
In the "Connection" pane select "File System" as the publish method, and give it a suitable target location.
In the "Settings" pane choose the appropriate configuration (in your case probably "Debug"), and set any other options that you'd like.
Then press "Publish", and the project should be built, and then deployed to the new file location.
You should then be able to start the emulator from this newly published location, which will be using your transformed web.config.
I have found this solution and it works perfectly
https://translate.google.co.il/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.sascha-dittmann.de%2Fpost%2FWebConfig-Transformation-im-Windows-Azure-Compute-Emulator.aspx&anno=2
I just installed VS 2013, upgrading from VS 2010. Creating a web deployment package zip file used to work in 2010. using VS 2013's Publish Web feature to publish to a Web Deploy Package, I getting the following error:
Web deployment task failed. (Object of type 'manifest' and path
'D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.SourceManifest.xml'
cannot be created. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
The details in the Web Publish Activity tab shows the following:
Transformed Web.config using D:\dev\DMWeb\DMWebClient\Web.Test.config
into obj\Test\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Views\Web.config into
obj\Test\CSAutoParameterize\transformed\Views\Web.config.
Auto ConnectionString Transformed obj\Test\TransformWebConfig\transformed\Web.config into
obj\Test\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish: obj\Test\Package\PackageTmp.
Packaging into D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.zip.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(3883,5):
Error ERROR_EXCEPTION_WHILE_CREATING_OBJECT: Web deployment task failed. (Object of type 'manifest' and path
'D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.SourceManifest.xml' cannot be created.
Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
Package failed.
In VS 2010, I've had to run it as Administrator for deploy to work, and I'm doing so here as well. I've also tried giving Full Control permissions to the project folder to NETWORK SERVICE, LOCAL SERVICE, Authenticated Users, and myself.
In the Package folder, there is the PackageTmp folder (which looks good), and the DMWebClient.SourceManifest.xml file, and that's it. In VS 2010, there's more files there.
DMWebClient.SourceManifest.xml contains:
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<IisApp path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp\App_Data" setAclResourceType="Directory" setAclAccess="Write" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp/DMWeb.config" setAclResourceType="File" setAclAccess="Read,Write" />
</sitemanifest>
In VS 2010, the last line containing DMWeb.config doesn't exist. On top of that, the path to it is wrong. It should be under the App_Data folder.
DMWeb.config is specified in Web.config like this:
<appSettings file="DMWeb.config">
Any help would be greatly appreciated.
This can also happen if there are any files in your project that have been moved, deleted, or renamed from the file system such that Visual Studio doesn't know where to find them.
My error was allmost identical:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
(3883): Web deployment task failed. (Object of type 'manifest' and
path
'D:\B\280\Binaries_PublishedWebsites\ProjectName\ProjectName.SourceManifest.xml'
cannot be created. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
The reason I found out is in the ProjectName.SourceManifest.xml file.
There is a line: <appHostConfig path="Default Web Site/ProjectName" />
If this webapp and site does NOT exist on the buildmachine, the error occurs. Once I created a dummy webapp site with the same name on the same site, it built!
And solved by removing that section with MsBuild parameters: /p:IncludeIisSettings=false /p:IncludeAppPool=false (i had those 2 to true, so only applies when you have them true)
Found out that I had an old .wpp.targets file from VS 2010, it was called ~DMWebClient.wpp.targets. In VS 2010, by renaming it, it would ignore it and not apply it. It seems like VS 2013 applies any .wpp.targets files regardless of the file name.
By removing that file, web deploy works again.
Thought I would add as none of the other answers fixed my problem, though perhaps more related to Lightswitch Web Deploy than ASP.NET Web Deploy (though OP doesn't specify which).
There are three projects within a standard Lightswitch Template solution. Two of them might be named lightswitchapp.HTMLClient and lightswitchapp.Server. Neither of these should be deployed! You should deploy the third project lightswitchapp.
I had been getting errors like this, which led me to this page.
Web deployment task failed. (Object of type 'manifest' and path 'manifest xml hidden' cannot be created. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
Great answer above, regarding the Lightswitch Web Deploy...couldn't find anything about it anywhere...kept thinking MS broke this on purpose because they don't want to support LightSwitch anymore...
In any case, once you go through the steps on publishing the main project from the LightSwitch template, a new problem arises, regarding the publish params if you push to a local IIS.
For all of you struggling with that...first install
httpPlatformHandler_amd64.msi
WebDeploy_amd64_en-US.msi
then, make sure "Web Deployment Agent Service" is running as a service
then, in Visual Studio (I am on VS2015 community), on the Publish Settings tab in the wizard, make sure you have something like this:
Service URL:
http://localhost/MSDEPLOYAGENTSERVICE
Site/Application:
Default Web Site\trax01
where trax01 is the name of your web app that runs under Default Web Site (please notice the back-slash before "trax01" compared to the forward-slash in the label for the setting.
Hope it helps somebody else, because this thing ate my liver! :)
The same exception can still happen in Visual Studio 2019. Additional detail for me was Object of type 'manifest' and path 'manifest xml hidden' cannot be created.
In my case the problem was a MsDeployDeclareParameters item in the {ProjectName}.wpp.targets file. It was attempting to set ACL permissions for the downloads folder, but the folder didn't contain any files so it wasn't present in the staging area.
Adding a file to the downloads folder resolved the problem (as would removing the MsDeployDeclareParameters entry from the {ProjectName}.wpp.targets file).
I tried many Solution by updating security to TLS 1.2 (X)
Removed * or special character from variables and password.
But later I found that, we have * in the password of connectionString in web.config.
I changed my password and it started working for me.
I'm struggling to get web.config transformations working with automated builds.
We have a reasonably large solution, containing one ASP.NET web application and eight class libraries. We have three developers working on the project and, up to now, each has "published" the solution to a local folder then used file copy to deploy to a test server. I'm trying to put an automated build/deploy solution in place using TFS 2010.
I created a build definition and added a call to msdeploy.exe in the build process template, to get the application deployed to the test server. So far, so good!
I then tried to implement web.config transforms and I just can't get them to work. If I build and publish locally on my PC, the "publish" folder has the correct, transformed web.config file.
Using team build, the transformation just does not happen, and I just have the base web.config file.
I tried adding a post-build step in the web application's project file, as others have suggested, similar to:
<target name="AfterBuild">
<TransformXml Source="Web.generic.config"
Transform="$(ProjectConfigTransformFileName)"
Destination="Web.Config" />
</target>
but this fails beacuse the source web.config file has an "applicationSettings" section. I get the error
Could not find schema information for the element 'applicationSettings'.
I've seen suggstions around adding arguments to the MSBuild task in the build definition like
/t:TransformWebConfig /p:Configuration=Debug
But this falls over when the class library projects are built, presumably because they don't have a web.config file.
Any ideas? Like others, I thought this would "just work", but apparently not. This is the last part I need to get working and it's driving me mad. I'm not an msbuild expert, so plain and simple please!
Thanks in advance.
Doug
I just went through this. Our build was a bit more complicated in that we have 8 class libraries and 9 web applications in one solution. But the flow is the same.
First off get rid of your after build target. You won't need that.
You need to use the MSDeployPublish service. This will require that it be installed and configured properly on the destination server. Check the following links for info on this part:
Note that the server in question MUST be configured properly with the correct user rights. The following sites helped me get that properly set up.
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html
How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?
The next part requires that your build definition have the correct MSBuild parameters set up to do the publish. Those parameters are entered in the Process > 3.Advanced > MS Build Arguments line of the build definition. Here's a hint:
(don't change the following for any reason)
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=False
/p:MSDeployPublishMethod=WMSVC
/p:SkipExtraFilesOnServer=True
/p:AllowUntrustedCertificate=True
(These control where it's going)
/p:MSDeployServiceUrl="https://testserver.domain:8172/msdeploy.axd"
/p:UserName=testserver\buildaccount
/p:Password=buildacctpassword
/p:DeployIisAppPath="MyApp - TESTING"
Obviously the user will have to be configured in IIS on the target server to be allowed access to that axd (see previous links). And the IisAppPath is the name of the website on the target server.
You won't have to do anything special for the config transformations as the build itself will take care of that for you. Just have the correct setting in the line at Process > 1. Required > Items to Build > Configurations To Build.
Instead of trying to do the deploy by adding tasks myself into the build process template, I followed advice in Vishal Joshi's blog post here.
Now the entire project is built and deployed and the web.config transformations work also. Brilliant!
I now have another problem to solve! The web application references web services and the build process results in an XmlSerializers dll. However, although this is built OK, it does not get deployed to the web host. I think this needs a new post!
Doug
For a BizTalk project, where does Studio stores the deployment details? I opened the dtproj and csproj files in notepad, but found relative entries which store the deployment details (like application name, Db name etc).
The servername and managementdatabase name are stored in the ".btproj.user" file.
<VisualStudioProject>
<BIZTALK>
<Build>
<Settings>
<Config
Name = "Development"
RestartHostInstances = "False"
Register = "True"
Redeploy = "True"
ConfigurationDatabase = "BizTalkMgmtDb"
Server = "MYSERVER"
/>
The applicationname are stored in the ".btproj" file
<VisualStudioProject>
<BIZTALK>
<Build>
<Settings>
<Config
ApplicationName = "MyBTSApp"
/>
The reason for having database and server config in the '.btproj.user' (which normally is not under source control) is that the Visual Studio deployment feature main focus is for development scenarios where one users settings might differ from another.
It basically exports its "c:\documents and settings[user]\Application Data\Microsoft\Deployment\BindingFiles" or somewhere around there.
Right click on the project and browse it's property sheets. You'll find the necessary entries. Now keep in mind, this is only for deployment from the dev studio. You want to change control your binding files like source code in your deployment packages.
have been given a URL to a WSDL, a piece of it is here..not sure if this is a pertinent piece or not. I know how to add the web reference and import the namespace in Visual Studio 2005.
Questions...how do I pass my values to it? How do I encode for binary-64? I have the methodname (GETP)...not sure how to invoke it as a function to pass parameters, or if that is even the correct way to do it with this type of reference. Have only consumed .asmx files previously.
<wsdl:message name="GETPResponse">
<wsdl:part name="GETPReturn" type="xsd:string" />
</wsdl:message>
<wsdl:message name="GETPRequest">
<wsdl:part name="BASE64DATA" type="xsd:base64Binary" />
</wsdl:message>
<wsdl:portType name="Dist">
<wsdl:operation name="GETP" parameterOrder="BASE64DATA">
<wsdl:input message="impl:GETPRequest" name="GETPRequest" />
<wsdl:output message="impl:GETPResponse" name="GETPResponse" />
</wsdl:operation>
</wsdl:portType>
Just use "Add Service Refrence" and point it to the WSDL. See "How to Consume a Web Service".
This site has how to create a WSDL class and use that, or how to reference the web service using a Visual Studio web reference: https://msdn.microsoft.com/en-us/library/ms155134.aspx
Neither option worked for me. I needed to create the WSDL class like at that site, but the web reference didn't work for me, and neither did just adding that class to my App_Code folder and trying to instantiate it. So I opted to create an assembly out of the WSDL class, then reference that assembly in my project. This was the only way I could get any useful classes/methods available to me. Here are my general steps, from start to finish, that worked for me.
Ensure you have the right URL at the top in your ASMX.cs file of your web service: [WebService(Namespace = "http://localhost:99999/WebService1.asmx")]
Leaving that as the default "tempuri.org" will cause you unbearable grief.
Get the Windows SDK for your workstation/server & install.
On a command line, navigate to WSDL, which for me on Server 2012 was: cd C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
Then, use this: wsdl /l:CS /protocol:SOAP http://localhost:99999/WebService1.asmx?wsdl
You can then do one of 2 things:
The proxy class will be generated in that same folder where you navigated on the command line. Go to it in Explorer, copy it into a
new Class Library Visual Studio project, at the root of the
solution. (For details, go to
https://msdn.microsoft.com/en-us/library/cc175801(v=vs.90).aspx and
skip to "Creating a Project for the Proxy Assembly".) Sign the
assembly (details on that same site, section "Signing and Building
the Proxy Assembly"). (I didn't bother with the serialization
exceptions or struct stuff - just those 2 sections, only.)
-OR- (easier)
Just use CSC to build your assembly:
Move your proxy class to the
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 folder.
Launch a command line and cd to that folder.
Run this command:
csc /t:library MyWebServiceProxyClassFile.cs /reference:System.Web.Services.dll /optimize
Obviously, replace "MyWebServiceProxyClassFile" with the name of your proxy class file. It will give you a DLL file with the same name as your proxy class.
Import the assembly in your client project by going to Add Reference and browsing to the assembly in that proxy project you just built in step 4. It should be in the MyServiceProxy\bin\Debug folder. (Or browse to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 if you left it there, from using CSC.)
Instantiate using the class name of your web service:
YourClass service = new YourClass();
You should see the webmethods available when you do service. with intellisense.
You'll likely need to add these parameters:
service.Url = "http://localhost:99999/WebService1.asmx";
service.Credentials = CredentialCache.DefaultCredentials;
(Add using System.Net; to the top of your class to use that last one.)
For those saying this is the "old" or "obsolete" way of doing it, I say this worked for me, and would say to tell Microsoft to make it work using the web reference and we wouldn't have to do it this way. Besides, this is largely their documented process, after all, with some of my own findings put in. And I noticed something else - svcutil generates a totally different, WCF-compliant proxy class, which WSDL does not, so be careful what utility you are actually using - they are NOT created equal.
Also, I made my own batch file for creating a proxy class from a web service, then building an assembly from it using CSC, like I have above:
echo off
cls
cls
set /P svc="Input the URL to your web service's Service.asmx file: "
cd \
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
wsdl /l:CS /protocol:SOAP %svc%?WSDL
set /P name="Type the name of the service's class' name (no .cs on end): "
move %name%.cs C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\%name%.cs
cd \
cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
csc /t:library %name%.cs /reference:System.Web.Services.dll /optimize
move %name%.dll C:\%name%.dll
move %name%.cs C:\%name%.cs
echo Your DLL and Proxy Class are waiting for you at
echo.
echo C:\%name%.dll
echo.
echo. and
echo.
echo. C:\%name%.cs
echo.
explorer.exe C:\
pause
cls
exit
This is set up to run on Server 2012 with the Windows SDK installed. You could run it on any platform if you change the place wsdl is found to point to Visual Studio's SDK folder, if you install that, ex:
cd "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin"
instead of that NETFX Tools folder.
You would use it by first entering the URL of the web service, ex.
http://localhost:99999/WebService1.asmx
When the class is generated, you give this program the name of the class file, minus the .cs. It should also be the same as the default class name at the top of WebService1.asmx.cs, in my example.
It will then leave the proxy class and assembly file at the root of C: for you.
For those wishing to pursue converting the ASMX into a WCF interface, I found this: https://msdn.microsoft.com/en-us/library/vstudio/ms751529%28v=VS.100%29.aspx
that looked promising, which has you use svcutil to produce the proxy, I'm assuming add it to an ASP.NET App_Code folder (it doesn't say) and add a service reference to the ASMX web service URL, but not a lot of detail/guidance on how to name the contract and where to put that <client> snippet in the web.config, though I believe it goes in <system.ServiceModel>.