In .NET core project why we use LoginAttempCount in appsettings.json file. what is its purpose to use.
"LoginAttempCount": "3",
This is used in my project
anyone can tell me?
These are custom settings. In core you have to mention your own properties which you can used across the application. The purpose of these settings is to make it constant and you can change it only single point of change which is very easy to maintained.
Related
This is more question of curiosity, the behavior is annoying, but something I can live with.
I'm working on 64b only C++ application in Visual Studio. It consists of more projects, and I deleted the Win32 Configurations from all of them (and also Win32 Solution Configuration). But, when I add new project, it is Win32, and also creates Win32 + MixedPlatforms Solution Configurations, and I need to go to Configuration Manager and delete those.
Is there any configuration how to forbid this? I'm using VS2012.
Thanks
It is pre-baked in the project template that you selected to get your project started. VS2012 makes it easy to customize that template. Get started with your favored standard template. Modify it, like using Build + Configuration Manager to first add the platform target you want, then deleting the Win32 configuration you don't want. Etcetera.
Then use File + Export Template. Keep the "Project template" selection, Next, fill out the dialog and save it. Presto chango, pick that template for your future projects.
I have an Asp.NET MVC site that I manage multiple instances of. Each instance uses it's own database but the code base is all the same. To facilitate this I have several build configurations with matching web.config transforms, so that when I publish it doesn't use my development database but instead uses the specific database for that site instance.
The problem with this came today when I went to publish an update to one of the sites. I forgot to change the build configuration, so my publish to site A was using a web.config transform that was meant for site B, and mayhem and confusion ensued.
Is there any way to to specify that a specific publish target will ONLY be used with a specific build configuration?
Or is there a better way to handle this situation than juggling build configurations?
One way to deal with this sort of thing, and I'm not certain it's the best, but it is a way, is to set certain configuration values in a higher level web.config or machine.config file that always resides on the machine in question.
Then just make sure that your project files don't override those configuration values.
Here are some considerations if you do this.
If you want to source control these values, it can be more difficult
this way (this could be a pro or a con depending on your
environment).
If other virtual sites are on the same machine and use the same
configuration values, this could affect them all, and if multiple
sites do use that same configuration value, changing it at the
source will change them all (again, could be a pro or a con
depending).
If something is wrong with the value, it can be harder to
determine where the problem is or what is causing it.
Getting to machine.config may be difficult in your organization
or with your hosting provider depending on your access/security
privileges, and it's not always possible to put a web.config at a
higher level than your application.
Obviously the good thing here is that you can have a different value configured on each machine and as long as these values are not also set in your web.config (which would probably result in an error), you won't have to worry about compiling different versions.
I believe that Visual Studio 2010 has a way for setting different config files for different build types, but that sounds pretty much like what you are already doing, so forgetting to build the right way can still end up with similar results.
You could attempt to set up continuous integration with something like TFS Build if that is available to you, in which case what gets built for prod could be set up to always work a certain way and always pull from the correct build type.
Hope something here helps.
Maybe you could go a solution where you don't rely on the 'Publish' dialog of the web application that requires you to make the right setting every time, but instead use a automated command-line like solution (batch file, your own msbuild target, or a build server like CStroliaDavis suggested [cruisecontrol, tfs, teamcity]).
You can just call the 'package' target from command line which creates a package:
msbuild MyWebProject.csproj /t:Package /P:Configuration=Release;DeployIisAppPath="Default Web Site/Main/MyWebProject";PackageLocation="F:\MyWebProjectDeploy.zip"
This also creates a *.cmd file so you can deploy it like this:
F:\MyWebProjectDeploy.deploy.cmd /Y -allowUntrusted /M:http://webserver/MSDeployAgentService /U:Administrator /P:"Secret"
You can add a custom *.msbuild file to your solution that performs these actions, or maybe it's easiest to just add a command to Tools -> External tools.
With kwateeSDCM you can not just deploy apps and web applications but you can also manage instance-by-instance parameters or file overrides. I've only used it with tomcat wars but it's not tied to a language or a platform so I suppose it should be straightforward to configure it to work with ASP.NET as well.
I'm currently implementing a vsix extension tool window which will soon need a database connection string for querying some data to display to the developer in the tool window. I'd like to make this connection string configurable by the developer. As the developer is unlikely to change the config settings often a file would be sufficient.
Is it possible to just use an app.config file in the same folder as the sln file and if so must I use some custom configuration settings to wrap the file? NuGet seems to implement this approach but I don't fully understand the internal architecture to see how the config file is used.
I'd appreciate any alternative approaches too.
Edit:
I have since realised that the dynamic data the config store would serve must be solution specific so that a tool window used in one solution can use different properties to that of another solution. I guess one possibility would be to use the .settings file to store the location of a single config file that itself stores information related to different solutions.
The best place to store settings for a .vsix extension is to use a .settings file. In order to create one do the following
Right Click on the project and select "Properties"
Go to the Settings Tab
Click on the link to create a default settings file
This will create a couple of files in your solution.
Settings.settings
Settings.Designer.cs
Additionally it will bring up a designer from which new settings can be added. These can be accessed afterwards by using the Settings.Default static property
Been there and in my opinion the built-in mechanism works best, detailed walkthrough: http://msdn.microsoft.com/en-us/library/ff460144.aspx
Adding a note from self I can see that the underlying implementation uses system registry subkey. However after VSIX extension uninstalled all the keys are removed automatically so your extension is not polluting the system leaving orphaned entries.
I have a Visual Studio web application solution. I have three projects as UserInterface, BusinessLogic and DataAccess.
I had to store some user defined settings and I created configSections in the config file.
I access these configSections through classes which inherit from .NET's ConfigurationSection base class.
So in short for every project I had a separate configSection and for that corresponding configSection I had a class in that project inheriting from ConfigurationSection to access the config section settings.
This works all sweet. But the problem arises if there is any setting which I need to use across multiple projects. So If I need to use a setting defined in UserInterface project configSection in, let say, BusinessLogic project I have to actually make a copy of that setting in the BusinessLogic's configSection. This ends up having the same setting copied across multiple configSections.
Isn't this a bit too redundant?
Never actually done this, but in theory it might work...
When you define your custom configuration section, set its configSource to an external file (whatever.config). This external file should be added to the SOLUTION and not the project. It will appear under "Solution Items". In each project, Add an Existing File, browse to whatever.config, click the dropdown on the Add button and select "Add as Link."
Whatever.config will be a single file you can edit under Solution Items, and it gets copied into each application at compile time.
Using your example:
Just create the setting in the Business Logic project and then expose a Getter to the User Interface project.
Then the UI can query the BL for the value. Your configuration setting is only in one place - the lowest level it can be.
However, if you replace a lower level project with a new one you'll have to make sure that the setting is replicated too. This is only likely to be an issue if the setting is in the Data Access level as that's the one most likely to get changed (different database provider for example).
There is a much better way of doing this using "Shared Projects" see my Answer on a very similar question here.
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.