my question is do I need to convert or make any changes to web.config file of solution (web application) of vb or only if I convert the .vb files to .cs files that will be enough?
And if any other changes I have to make or any suggestions please do tell me, this is my first time with vb so I am not that knowledgeable.
Well, you no doubt starting a whole new project from scratch. I would let it create it own web.config. And then say in settings create your conneciton strings etc. (assuming you using settings).
And setting up references etc. will also often put assembly references in that web config. You might be able to just copy the whole web config, and do the reverse (remove some things).
I would actually start with a fresh web config, since it would be a chance to leave behind a lot of stuff and things that often get built up over the years. However, I don't really see what the benefits are of spending that money to convert from vb to c#. If I was spending that kind of money, then I would make the jump to mvc and the newer .net stack.
So, you probably can just copy the web config over, but I would take this opportunity to start with a fresh one, and then wind up adding the little bits and parts you need as you convert to c#. That way you wind up with a much cleaner web.config file.
so you can and should be able to just copy the config file over to the new project - but I would not for above reasons.
As noted, I can't see how this cost can be justified unless you migration is to a newer technology anyway.
only changing the code-behind files worked for me, did not change the config file.
Related
I need to change the config file myApp.exe.configat runtime. How to make sure that the program would be started to work with a modified file without leaving the program?
It may be necessary to use a ConfigurationManager.
Thank you!
It's definitely possible, I did this at work a while back. Essentially, you can load a new app.config file into memory, then tell .NET to use the new file. From that point on, all variables in the Configurarion section change when read using the standard .NET calls.
Sorry I cant give specifics, you might have to Google some more - but at least you know its possible!!
Having said this, I believe this is the wrong architectural path to go down. Far better to store your settings in an external file in your own format. It really is a royal pain to update app.config, and if we hadnt had to do it for compatibility reasons with legacy assemblies it would not have been worth it in the least. The legacy assemblies used WCF which in itself was a mistake. WCF is a ghastly architectural morass, with few redeeming features compared to any of the modern alternatives.
Update
See Overriding App.Config settings.
See Change default app.config at runtime.
Having a server that other devs use, I currently log the version of the dll they use. I do that by having the client that use Reflection to retrieve its version:
Assembly.GetEntryAssembly().GetName().Version.ToString();
It's nice, but since it come from dev that uses TFS and do themself the build, I can not see if they have the latest version of the sources. Is there a trick, like a compilation tag, that would easily allow a hash of the generating source code?
Note: I have try to send the MD5 of the dll (using assembly.Location), but it is useless since the hash value changes between 2 compilations (I suppose there is some compilation timestamp inside the generated dll).
This is most collaboraton issue then a coding.
In the moment that you find out that the version is old one.notify them about it.
If the real version is not old one, that means that developers before making buold did not increment the version ID, which is mistake.
In other words, ordanize it among people, and not relly on these kind of tools (if there is any). You trying to create a complicated tool, that will help you avoid mistakes, but humans will find a way to make them again.
So it's better to create solid relation structure among you, imo.
Create a tool on pre build event to hash/last-write-time your code files.
Write the result to a cs file or a embedded resource file.
The result file must exclude in above action.
For prevent skip build (up-to-date) feature not work,Compare the file before write.
And if youre opening the file in IDE will get a prompt `changed from out side' when build.
Seem there is no easy way to do it.
i am creating my own CMS frame work, because many of the clients i have, the have same requirements, like news module, newsletter module, etc.
now i am doing it fine, the only thing that is bothering me, is if a client wants to move from my server he would ask me to gibe him his files, and of course if i do so the new person who will take it he will see all my code, use it and benefit from i, and this is so bad for me that i spend all this time on creating my system and any one can easily see the code, plus he will see all the logic for my system, and he can easily know how other clients of mine sites are working, and that is a threat to me, finally i am using third party controls that i have paid for their license, and i don't want him to take it on a golden plate.
now what is the best way to solve this ? i thought it is encrypting, but how can i do that and how efficient is it ?
-should i merge all my CS files and Dlls in bin folder to one Dll and encrypt it, and how can i do that ?
i totally appreciate all the help on this matter as it is really crucial for me.
you should read this
Best .NET obfuscation tools/strategy
How effective is obfuscation?
In my experience, this is rarely worth the effort. Lots of companies who provide libraries like this don't bother obfuscating their code (Telerik, etc).
Especially considering what you are writing (CMSes are everywhere), you'd likely see more benefit from your time spent implementing features that put your product/implementation in a competitive advantage and make companies see that the software you are capable of writing has value, rather than the code itself.
In the end, you want to ensure you are a key factor in making software work for a company, not the DLLs you give them.
You'll need to precompile your site and obfuscate dlls.
Visual Studio has something like Dotfuscator Community Edition shipped with it. You could give it a try.
Of course, HTML output, CSS declarations, database structure and stored procedures code cannot be encrypted.
You can however try to compress CSS which will also reduce its readbility by humans.
Check here: The best approach to scramble CSS definitions to a human-unreadable state throughout an ASP.NET application
One other idea would be to use a frame in your HTML and put the most of the site pages inside of it. This way, it will not be visible when doing "View source".
Or just state it clearly that you offer whatever you're doing as a service and do not provide source codes of your work. I somehow doubt salesforce would be willing to give their sources to anyone who asks.
The way I currently handle this is by having multiple config files such as:
web.config
web.Prod.config
web.QA.config
web.Dev.config
When the project gets deployed to the different environments I just rename the corresponding file with the correct settings.
Anyone have suggestions on how to handle this better?
EDIT:
Here are some of the things that change in each config:
WCF Client Endpoint urls and security
Custom Database configs
Session connection strings
log4net settings
Scott Gu had an article on this once. The solution he presented was to use a Pre-build event to copy the correct config into place depending on the build configuration chosen.
I also noticed that there already is a similar question here on SO.
Transforms seem really helpful for this. You can replace certain sections with different rules.
http://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx
The way we've been doing it is to override the AppSettings section:
<appSettings file="../AppSettingsOverride.config">
<add key="key" value="override" />
...
</appSettings>
This only works for the appSettings section and so is only useful to a degree. I'd be very interested in more robust solutions.
Edit Below
Just watched this:
http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/
VS2010 has config transforms which look pretty awesome, should make multiple configurations a complete breeze.
In Visual Studio, I create xcopy build events and I store all the config files in a /config folder. You only need one event for all configurations if you name your files after the build configuration: i.e. overwriting web.config with /config/web.$(Configuration).config
My favorite way to tackle this is with the configSource attribute. Admittedly I only use this on one element (<connectionStrings>) but it does provide an easy way to swap in and out different segments of a web.config (which I do during install time via a WebSetup project).
I also use the web.DEV.config, web.TEST.config, web.PROD.config etc.
I find this way the most easiest, simplest and straight-forward way if your projects are not complex. I don't like making things more complicated than neccessary.
However, I have used NAnt and I think it works well for this. You can set up builds for your different environments. NAnt takes some reading to learn how to use it but it's pretty flexible.
https://web.archive.org/web/20210513225023/http://aspnet.4guysfromrolla.com/articles/120104-1.aspx
http://nant.sourceforge.net/
I used it along with CruiseControl.net and NUnit to perform automatic daily builds with unit test validation and thought they worked well together.
It really depends on what the difference is between the environments that is causing you to use different web.config files. Can you give more information as to why each environment currently needs a different one?
We have a few workarounds (not all of them are done with web.config but the same idea)
We include multiple configuration files in the packaged deployment. During installation we specify environment that we are installing on.
Migrate all environment specific settings to the Database server for that environment. WebServer provides its environment when requesting server name
Provide multiple settings (1 per environment) and using code request different settings.
Combination of 2 and 3 (Override a part of the settings based on the environment - for example application server name)
Through most different version management software (subversion, git, etc) you can ignore specific files.
Thus, in subversion, I'd have:
configure.template.php - This file is versioned and contains templated configuration data, such as empty DSN's
configure.php - This file is ignored, so that changes to it do not get tracked.
In subversion, the way to do this is:
svn pe svn:ignore .
It'll open your editor, then you type
configure.php
Save, exit, checkin your changes, and you're good to go.
I'm really confused by the various configuration options for .Net configuration of dll's, ASP.net websites etc in .Net v2 - especially when considering the impact of a config file at the UI / end-user end of the chain.
So, for example, some of the applications I work with use settings which we access with:
string blah = AppLib.Properties.Settings.Default.TemplatePath;
Now, this option seems cool because the members are stongly typed, and I won't be able to type in a property name that doesn't exist in the Visual Studio 2005 IDE. We end up with lines like this in the App.Config of a command-line executable project:
<connectionStrings>
<add name="AppConnectionString" connectionString="XXXX" />
<add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>
(If we don't have the second setting, someone releasing a debug dll to the live box could have built with the debug connection string embedded in it - eek)
We also have settings accessed like this:
string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];
Now, these seem cool because we can access the setting from the dll code, or the exe / aspx code, and all we need in the Web or App.config is:
<appSettings>
<add key="TemplatePath_PDF" value="xxx"/>
</appSettings>
However, the value of course may not be set in the config files, or the string name may be mistyped, and so we have a different set of problems.
So... if my understanding is correct, the former methods give strong typing but bad sharing of values between the dll and other projects. The latter provides better sharing, but weaker typing.
I feel like I must be missing something. For the moment, I'm not even concerned with the application being able to write-back values to the configuration files, encryption or anything like that. Also, I had decided that the best way to store any non-connection strings was in the DB... and then the very next thing that I have to do is store phone numbers to text people in case of DB connection issues, so they must be stored outside the DB!
If you use the settings tab in VS 2005+, you can add strongly typed settings and get intellisense, such as in your first example.
string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;
This is physically stored in App.Config.
You could still use the config file's appSettings element, or even roll your own ConfigurationElementCollection, ConfigurationElement, and ConfigurationSection subclasses.
As to where to store your settings, database or config file, in the case of non-connection strings: It depends on your application architecture. If you've got an application server that is shared by all the clients, use the aforementioned method, in App.Config on the app server. Otherwise, you may have to use a database. Placing it in the App.Config on each client will cause versioning/deployment headaches.
Nij, our difference in thinking comes from our different perspectives. I'm thinking about developing enterprise apps that predominantly use WinForms clients. In this instance the business logic is contained on an application server. Each client would need to know the phone number to dial, but placing it in the App.config of each client poses a problem if that phone number changes. In that case it seems obvious to store application configuration information (or application wide settings) in a database and have each client read the settings from there.
The other, .NET way, (I make the distinction because we have, in the pre .NET days, stored application settings in DB tables) is to store application settings in the app.config file and access via way of the generated Settings class.
I digress. Your situation sounds different. If all different apps are on the same server, you could place the settings in a web.config at a higher level. However if they are not, you could also have a seperate "configuration service" that all three applications talk to get their shared settings. At least in this solution you're not replicating the code in three places, raising the potential of maintenance problems when adding settings. Sounds a bit over engineered though.
My personal preference is to use strong typed settings. I actually generate my own strongly typed settings class based on what it's my settings table in the database. That way I can have the best of both worlds. Intellisense to my settings and settings stored in the db (note: that's in the case where there's no app server).
I'm interested in learning other peoples strategies for this too :)
I think your confusion comes from the fact that it looks like your first example is a home-brewed library, not part of .NET.
The configurationmanager example is an example of built-in functionality.
I support Rob Grays answer, but wanted to add to it slightly. This may be overly obvious, but if you are using multiple clients, the app.config should store all settings that are installation specific and the database should store pretty much everything else.
Single client (or server) apps are somewhat different. Here it is more personal choice really. A noticable exception would be if the setting is the ID of a record in the database, in which case I would always store the setting in the database with a foreign key to ensure the reference doesn't get deleted.
Yes - I think I / we are in the headache situation Rob descibes - we have something like 5 or 6 different web-sites and applications across three independent servers that need to access the same DB. As things stand, each one has its own Web or App.config with the settings described setting and / or overriding settings in our main DB-access dll library.
Rob - when you say application server, I'm not sure what you mean? The nearest thing I can think is that we could at least share some settings between sites on the same machine by putting them in a web.config higher in the directory hierarchy... but this too is not something I've been able to investigate... having thought it more important to understand which of the strong or weak-typed routes is 'better'.