Consider the following scenario:
Alice creates Web application (ASP.NET MVC or WebForms) using Visual Studio 2012.
Alice creates a Publish Profile called "PRODUCTION" and chooses "Release" configuration in the Settings tab (in the Publish Wizard).
Alice publishes the application using the Publish Profile called "PRODUCTION".
Alice saves the solution into source control.
Note that by default the "*.pubxml.user" file is not included in source control: http://msdn.microsoft.com/en-us/library/ff398069.aspx
Bob does a Checkout of the solution from the source control.
Bob opens the solution and launches the Publish Wizard.
Bob sees the selected Publish Profile is called "PRODUCTION".
Bob clicks on Settings tab (in the Publish Wizard) and sees the displayed configuration is "Release".
Bob publishes the application.
Bob realizes the application was published using "Debug" configuration instead of "Release" configuration.
The reason is the information about the build configuration is stored in the file "*.pubxml.user" (See node called <LastUsedBuildConfiguration>).
This behavior is problematic especially when you use Web config transformations ("Web.Release.config") to change connection strings.
=> How can I fix this problem if I don't want to save "*.pubxml.user" file into source control (because this file can contains other information inappropriate for a public repository for example)?
Related articles:
http://connect.microsoft.com/VisualStudio/feedback/details/776066/publish-settings-windows-azure-publish-target-profiles-not-selecting-proper-build-configuration
http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx
http://msdn.microsoft.com/en-us/library/dd465337.aspx
There are two aspects to this; sharing the value in the drop down for the Publish dialog and support for command line. Below are my comments on both.
Sharing profiles with team members
When we released the publish bits in VS2012 RTM we were writing LastUseBuildConfiguraiton into the .pubxml.user file. We have since moved that to the .pubxml file itself so that it is shared with other team members. You can get the latest build at:
ASP.NET 2012.2
Latest Azure SDK
If you have installed one of those and you are still seeing the behavior where the Config is not shared that is likely because the .pubxml was created with an older drop. The solution is to delete the .pubxml and .pubxml.user file and create it again with the latest.
Command line scenarios
For command line scenarios the Configuration property needs to be set explicitly. The .pubxml (or .pubxml.user) file cannot override that value. For more details see my blog at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx.
If you have a backup of this Project then no need to worry about this error. Just run the backup project in VS 2012 OR 2013 and open the node of Property and then publish Profile folder and the then you will see there a single file with name of "Your project name.xml" now go to solution explorer menu press the button of "show all files" and you can see an other file with the name of "pubxml.user". Now right click on the publish Profile and click the option "open folder in file explorer" now copy the file and replace it with crashed file.
Now rebuild project and after that publish it.
I was getting this problem today with this project Hajj and Umrah Project now you can see that is live.
Related
In VS2015 community ed. I had two web deployment publish profiles set up with different server targets, like "development" and "live".
Occasionally I want to publish a single file instead of the entire web project, and I can right click on the file in solution explorer and select "publish", and it uploads it to the server.
I was able to switch between the two target servers using the configuration dropdown in the top bar:
I was able to switch freely between the two servers and upload to either one. Occasionally, if this didn't work, I could also go to the Build --> Publish menu, select the target, close without publishing, and then publish individual files by right-clicking in the Solution Explorer on the file and selecting Publish.
In VS2017 CE, this doesn't work anymore. No matter what I select from the profiles, I can only publish individual files to whatever target was selected in the previous full publish. I have to perform a full publish to the selected server, to get the target to change to that server.
Is there any way in VS2017 CE to publish individual files on the fly, to a specific target server using web deploy?
Look for the Web Publish Activity tab available next to Package Manager Console, Error List, Output, etc. There is a dropdown where you can select a publish profile.
I have an asp.net web application project that I am publishing via Build > Publish within visual studio 2013. I am publishing to the file system, using the precompile option selected. My project has "Only files needed to run this application" selected in the Package/Publish Web settings screen. However, regardless of what I do, the .cs files (code-behind) and designer.cs files get copied to the output folder during publishing.
This project was created by using the File > New Project > ASP.NET Web Application functionality in visual studio. Then files from a website project were added to the application, and the "convert to web application" command was run on it from the build menu. The conversion to a web app seems to have worked fine, but I am unable to publish without the .cs files being included.
What else needs to be done in order to get a web application to publish without the code-behind files included? Any ideas on what I can look into?
Could there be a setting at the solution level that is causing this? The new web application was added to a pre-existing solution with about a dozen other projects.
Another thing to note is that when I create a new web app with visual studio in a new project, and publish w/ the same settings, it does NOT include the .cs files.
I've also tried deleting and then creating a new publish profile.
I just fixed this by deleting my old publish profile and creating a new one.
The new one appeared to have all the same settings as the old one but when I published it didn't copy the .cs files.
Edit: This answer is a lie. There was a difference between the two profiles. The new profile was in Release configuration.
Edit 2: There's a setting in the project settings which determines what gets published. Select "only files needed to run this application" from the following page.
Turns out that I added this line to my csproj file earlier when I was trying to get my project to build on our build server. Removing it fixed the problem:
<Target Name="GatherAllFilesToPublish"></Target>
Is there any way to protect the code written in the cs files? Also for the database?
We designed a website and we're considering publishing it and we have to deliver the project as a college project, but we want to protect the code so we can secure it in case we publish it.
We are already considering publishing the site and then giving them its url but it's our last option.
What can we do in this case besides publishing the site?
Thanks :)
To compile your project into a single dll file, you have to use the Publish Web Site function of Visual Studio. I use Visual Studio Express 2012 (version 11), so if you don't have this version, then there could be slight differences.
Click on the "BUILD" menu, then select Publish Web Site
Create a new Profile if you haven't done so.
Click on 'Connection' on the left side menu of the window, and choose File System to save it on a folder on your computer
Click 'Settings'. Open up File Publish Options and select the following:
Click on the 'Configure' link of the second option in the above screenshot. This will open the following window. Here you can play around with the merge settings. I've tried the 3rd and last option on a test website, and the output was similar. The text (testwebsite) in the textbox is for the name of the DLL file.
Click 'Publish'
TFS generates a publish directory under the build agent working directory:
Z:\TFSBuilds\1\box\CT\Binaries\\_PublishedWebsites
I am supposing that this is where TFS is automatically publishing the site. How can I use it for auto publishing of sites... as Should we refer our IIS website to this directory. What is the purpose of it?
Firstly, the working directory is as the name says, a "working" directory. That is where the build agent downloads the source, perform compiles etc. It also clears the working directory whenever you run the build again so you risk grabbing unfinished artifacts when you try to retrieve from the working directory.
TFS defines a "drop folder" that it will copy the final artifacts to, once the build completes. You can define the drop folder for a build by editing it's build definition:
Right click on the build and choose 'edit build definition.
Select the 'Build Defaults' section.
Tick 'This build copies output files to a drop folder'
Enter an UNC path for the build agent to copy artifacts to (make sure the Build Agent has access to that UNC path!)
Secondly, in regard to _PublishedWebsites. The build agent will create a _PublishedWebsites folder for each Web project it builds as part of its build artifacts (so if you tell it to build a solution with 2 web projects, it'll create [Project name A]\_PublishedWebsites and [Project Name B]\_PublishedWebsites). Inside each _PublishedWebsites folder are the contents to be dropped into an IIS application, same as what you would get by right clicking on a web project and selecting 'Publish'. I normally add a last step in the build workflow to copy the contents of this _PublishedWebsites folder to my desired IIS directory.
This link tells you how to add the copy workflow: TFS 2010: Copy _PublishedWebsites to test server
And here's more on drop folders: http://msdn.microsoft.com/en-us/library/bb778394.aspx
This is the error I get:
Error 101 Could not load type
'control'. /Test.vbproj/x.ascx 1 1
WebDeployProject
This is a left over file that was part of the project last week, but one of the developers deleted it from the project. I have to manually delete the file in order to get the WDP to build. Is there a way to tell the WDP to ignore the files that are not part of the project or to see that these files are not part of the project and delete them?
You'll need to use your source control tools to find and remove local files that aren't under source control.
For instance, if you're using TFS, do the following:
Open Source Control Explorer (View -> Other Windows -> Source Control Explorer)
Right-click on the path in TFS that corresponds to your local working copy and select Compare
Use your TFS path as Source Path and your local working copy as Target Path
Under View Options, select "Show items that exist only in target path"
You've now got a list of all the files that exist in your local working copy but aren't in source control. For each file, either delete your local copy or add it to source control.
It could have something do to with the type of web project is it.
If it's a web site, then the compiler will attempt to compile every file in the folder. However, if it's a Web Application Project, then it will only compile those that you've specifically added as part of the project.
If you have recently deleted/removed a file from your project then you need go to Project > "Show all files" and all removed files will apear in your solution explorer. You can delete the file, /x.ascx and rebuild your WDP.
It has nothing to do with the type of Web project: http://amiraryani.wordpress.com/2008/11/06/web-deployment-project-aspparse-could-not-load-type/.
A Web Site itself considers files under its root directory as part of the site.
A Web Application Project itself allows you to customize build actions, etc. on a per-file basis.
A Web Deployment Project, however, will try to include files under the root directory (a la a Web Site), even if the WDP is associated with a WAP. That's why it doesn't matter which kind of Web project it is.
EDIT: To clarify, it would matter what type of Web project you are using if you were trying to Build, Debug, or Publish that project itself instead of using a WDP.