Just delete the language dll's that your application shouldn't support. .NET will automatically fall back on the default language (english) if it can't find a resource dll for the locale specified in the users regional settings.
Cheers
/Henrik
david.wendelken:
There are a set of resource files for each language.
Delete the resource files. I'm not sure if there will be references to them in assembly.info or not.
There are references to them in the proj file. But if you open the project in VS and delete the resx files (all but the primary one!!!!) that will remove all the satellite assemblies that are created for each language on the next build (and all subsequent builds).
The other posters are right though. Directly modifying the CSLA project almost certainly means you've chosen to lock into whatever version of CSLA you started with. If you are OK with being stuck there without bug fixes or enhancements that's cool - but that is the cost you pay by going down that road.
In any case, including CSLA directly into a business solution is generally a bad idea. It plays havok with the Windows, Web and WPF controls in particular, and can confuse the heck out of VS. Especially the Web controls will suffer from this problem. I don't view including the Csla project in a solution with a business project as a supported scenario - there are just too many issues around it, and the easiest solution to all of them is to keep the Csla project in a separate solution.
From a source control perspective, my recommendation (and what I actually do) is to put Csla.dll into your source repository. Then your business projects can reference THAT assembly. I do this with all third-party components, as it is the only way you can ensure that a given build of code in your repository is still buildable in the future.
The side-effect is cool. A year from now, you can go back and check out today's version of your code (along with all third-party binaries that code relies on) and do your build.
Obviously other issues, like the OS or Visual Studio changing, are harder to deal with in this manner, but the approach does solve a whole host of common build-from-history issues.
I also add 3rd party components to source control for exactly the same reasons. It is a very good idea.
Joe
What you are saying is to include CSLA in your solution using a FILE reference only? Don't use a PROJECT reference? I have not been doing that (but I will change it if it is considered best practice.)
And I am not sure I understand the question about source control. Are you saying that, for example, your BO class sets a file reference to CSLA.dll. Then, on build, the CSLA.dll is copied into the BIN directory of my BO project. ARe you saying to add THAT copy to Source Control?
Sorry for the question. I am still learning this stuff.
Seth
BTW, I am using Subversion for source control. Can you set a file reference directly to the source control version? Using Subversion?
Seth
BTW, I am using Subversion for source control. Can you set a file reference directly to the source control version? Using Subversion?
Seth
Yes, exactly.
I typically have a folder structure like this:
\Solution
\Csla
\UIproject
\Libraryproject
\www\DataportalHostproject
In the \Csla directory I put Csla.dll. Manually copied from
where I built the Csla solution.
That \Csla directory is in svn, along with everything else under
\Solution.
Then all the other projects do a FILE reference of
\Solution\Csla\Csla.dll.
If I want to update Csla.dll, it is a conscious choice. I
manually copy the new version of the DLL into the \Solution\Csla folder and
check it into svn. All the other projects automatically pick up the new
version, because they use a file reference from that location.
Rocky
From: Pawz
[mailto:cslanet@lhotka.net]
Sent: Monday, October 29, 2007 9:36 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] disable mult-language support
BTW, I am using Subversion for source control. Can you set a file reference directly to the source control version? Using Subversion?
Seth
I would imagine you'd put the CSLA dll in a seperate folder in your working
copy, then upload your working copy whenever you commit your changes, including
your 'ExtraDlls' folder with your upload. That way any changes to the DLLs
would automatically be detected and committed as well, and your reference would
be to the local file in your working copy, not on the SVN server.
Great,
That is exactly how I did it too after reading the post.
Seth
I'm wondering, have you've included the Csla project into your own, like as in the source code? If so, this is why they're building all the time.
Assuming this to be the case, this is what we do:
1. Compile Csla and make a copies of the Dll's.
2. Place these in a \binaries\ folder in our project. We reference the debug dll's for the project and use the release dll's for the installer. For debug dll's be sure to include the pdb files so that you can step into Csla if necessary.
3. For the installer you can use whatever language resource dll's you need (or none, just use Csla.dll for the English default), just include them in the package.
Hope this helps, if I'm understanding correctly.
Brian
Personally, I would advise against changing the CSLA framework source files. In fact I would advise against changing any framework source files, not just CSLA ones. Once you go down this route it becomes increasingly more difficult to manage "official" CSLA patches and upgrades.
By all means extend the functionality of the CSLA framework with your own specific extensions. That is what we did with CSLA and NHibernate. Importantly though, we did not change any source files from either of the two frameworks. Both remain "official" product releases and we are able to upgrade each of them independently of the other from "official" sources.
I really would suggest you try and set up your solution differently as suggested by a previous poster. There is really no need to have CSLA as part of your solution and continually keep re-building it.
You should treat CSLA as a fixed framework, just like you do with the .NET framework itself. Once you've built CSLA, just put the compiled assemblies in a fixed place and reference them in your project from there.
For example, we have a fixed folder called "3rdParty\bin" where we keep ALL 3rd party DLLs that we reference (CSLA, NHibernate, NMock, Castle, Telerik).
I agree with David.
You should have Base classes which inherit from CSLA.
Then all of your Business Objects should inherit from YOUR base classes.
This allows you to override or add behaviors for your work environment.
Joe
Count me as one more developer wanting to know how to turn off multi-language support. Can anyone here answer this question, or are we all preoccupied with how perfect the CSLA codebase is and why we shouldn't be touching it? Its a pretty simple question.
Thanks.
Agreed. See Henrik's post.
But unless you're writing a multi-lingual application, the extra resource DLLs would never actually be used anyway.
Think of it being like the .NET framework itself - you don't "turn off" multi-lingual support in that. It's always there, but you just don't use it if you don't need it.
Copyright (c) Marimer LLC