Home Dashboard Directory Help
Search

Remove Superfluous Language Folders in ClientGenerated & ServerGenerated Projects by Yann Duran


Status: 

Closed
 as External Help for as External


6
0
Sign in
to vote
Type: Suggestion
ID: 682914
Opened: 8/3/2011 9:37:41 PM
Access Restriction: Public
0
Workaround(s)
view

Description

There is a post in the LightSwitch forum, http://social.msdn.microsoft.com/Forums/en-US/lightswitch/thread/7addc212-417a-4025-83b1-ae304189d984/, that states:

I find it kind of ridiculous that by default there are 40 language folders in ClientGenerated/bin/Debug and ServerGenerated/bin/Debug and each one has a copy of about 10 different DLLs. I don't really need them and they're taking up close to 90MB of space.

Eric Gruber then suggests:

If this is something you'd like to have us consider changing in the future, could you enter this as an bug in Connect?

So here is that suggestion on Connect.
Sign in to post a comment.
Posted by Microsoft on 11/7/2011 at 2:46 PM
Hi Yann (and Paul). There are two specific issues here:

1. When building the projects, we are copying the localized versions of the assemblies during the build process. This is part of the basic reference resolution that happens when all projects with references to localized assemblies are built. I can reproduce the problem using a generic Silverlight project (without LightSwitch). The problem seems to be compounded by LightSwitch since we have several projects.

Unfortunately, there's nothing specific in LightSwitch we can do to resolve this issue since this is something that's done in the base .targets file during build.

However, the good news is that we're looking at ways to reduce the number of nested projects we use in the next version of LightSwitch so this problem may be reduced in future versions.

2. As for the request to not deploy assemblies that have not changed, this is difficult for us to change. We always need to push the lastest binaries to the server to ensure that the server has the latest copy of all referenced assemblies, otherwise the deployed application might not run correctly. In this case, we'd rather err on the side of taking slightly longer but ensuring the server is up to date with the most recent assemblies.

Thanks for your feedback.

- The LightSwitch Team

Posted by Paul Keister on 10/17/2011 at 2:14 PM
Even with a fast broadband connection (20 mbps) this issues adds at least a few minutes to deployment time. It would be nice to have the option to exclude all assemblies that haven't changed since the last deployment from the deployment package. The language assemblies are the most obvious problem in this regard.
Sign in to post a workaround.