17

I've migrated a large ASP.NET solution from Visual Studio 2008 (.NET 3.5) to Visual Studio 2010 (.NET 4.0).

I also installed the new version of the Web Deployment Project for VS 2010, because the solution also includes a web deployment project which I'm using to precompile .aspx/.ascx etc. into a single DLL.

I've noticed that the new version of the web deployment project takes way more time to compile and merge the assemblies - instead of 5 minutes in VS2008 it takes 15 or 20 minutes now in Visual Studio 2010.

Does anybody know what could be the reason for such a performance loss?

UDPATE

I ran Process Manager during the compilation. It showed me that aspnet_merge is spending a lot of time on accessing (file IO) assemblies which in my opinion should not be part of the merge process.

For example, even .NET Compact Framework assemblies which I am sure I'm not referencing in any way are accessed on file level (at least that's what Sysinternal's Process Manager shows me.)

splattne
  • 102,760
  • 52
  • 202
  • 249
  • Double check the `.wdproj`. Look at the `Import Project` xml element in the `.wdproj` and verify that the path to `Microsoft.WebDeployment.targets` is correctly pointing your VS2010 **Web Deployment Project** install directory. – Brian Chavez Mar 02 '12 at 11:59
  • @BrianChavez thanks for your help! The .targets file seems to be the right one pointing to the VS2010 version. – splattne Mar 02 '12 at 12:08
  • @splattne sorry that ask so question, but did you have clean your temporary folder (both vs temp and win temp) ? did you have defrag your disk ? Do you have clear the old VS reference ?- delete the .suo file – Aristos Mar 03 '12 at 10:24
  • Also Excludes the un needed reference from your solution via http://visualstudiogallery.msdn.microsoft.com/fc504cc6-5808-4da8-ae86-8d3f9ed81606 – Kamran Shahid Nov 08 '12 at 07:08
  • Any solution? I'm thinking of turning off merging unless the speed improves. – Nelson Rothermel Sep 25 '14 at 14:26
  • @Nelson no, sorry. Didn't find a solution. – splattne Sep 26 '14 at 06:20

5 Answers5

1

Do you use NuGet in your project? If so, try to remove auto load before build.

Roman
  • 665
  • 1
  • 9
  • 24
1

had about the same thing. checking processes and swapping showed lack of memory. VS2010 was swapping it's feet off. So upgraded memory to 6GB and works like sunshine. Whats your hardware config?

Ton
  • 316
  • 2
  • 12
1

Your problem is that the solution is very large and the web deployment project is copying it from one directory to another that's why it is taking that long, what you have to do is that you should exclude any unwanted folders from being deployed (images, files, anything not needed) to do so follow these easy steps:

  1. Right click on the web deployment project and click on Open Project File.

  2. in the wdproj file you will see a tag called <ItemGroup>

  3. Inside this tag add the following line: <ExcludeFromBuild Include=”$(SourceWebPhysicalPath)\FolderName\**\*.*” />

  4. Save and close your wdproj file and that’s it, you can try to build now.

Alex
  • 5,971
  • 11
  • 42
  • 80
1

I also installed the new version of the Web Deployment Project for VS 2010, because the solution also includes a web deployment project which I'm using to precompile .aspx/.ascx etc. into a single DLL

remove your current web deployment project and then add new: right click on Site -> Add Web Deployment project ( if you migrated current from VS 2008 ).

I have a solution with 100 projects and had bad filling when built it too ( about 15-20min ).. but then I have removed HDD and put SSD and now I'm happy.. 3-4 mins for build !

mastak
  • 1,397
  • 1
  • 14
  • 28
0

I think it was in ASP 4.0 that they started to include automatic JQuery library references. In the scripts folder there should be a jquery1.4.1.min.js remove that file from the project. minimized files are the same as the other one, but condensed to one line of code which is harder to compile, but better for servers. You can also just get rid of these libraries all together if you do not plan to use JQuery because it can be more of a complication for other things as well.

SinceForever
  • 232
  • 1
  • 2
  • 12