I need to provide private NuGet patch for the customers. We have more number of customers. We are in the position to provide different NuGet Patch to all needed customers. Now, I have followed below approach for provide NuGet patch
provided each NuGet feed link for each customer and maintain separate
NuGet package folder for each customer. But, we have maintained each
Web application for each customer. This is very complex and it’s not
possible achieve for more customers.
This is my code block
Web.Config
<appSettings>
<add key="requireApiKey" value="true" />
<add key="apiKey" value="" />
<add key="packagesPath" value="~/NugetPackages/customer1" />
<add key="enableSimpleMembership" value="false" />
<add key="" />
</appSettings>
I want to know other possibilities for to achieve this. My query is
For Example
My Feed link is - http://mydomain/packages/c1 and
http://mydomain/packages/c2 etc…
C1 feed link is want to show only NuGet package which is in customer1
package folder
C2 feed link iswant to show only NuGet package which is in customer2
package folder
But We need to maintain one web application for achieve these.
Is this possible or not? Could you please share your ideas?
Thanks in Advance
Mathan
I have posted same query in NuGet GitHub, I got some response. In NuGet server not yet released dynamic Feed URL feature, this is in development stage. I have shared that link here
https://github.com/NuGet/NuGetGallery/issues/3520
Regards,
Mathan
Related
Is there a way to get a web.config transformation in Visual Studio 2015+ to include the contents of an externally-referenced secrets file as described here?
This works well when developing locally, and doesn't include the file in source control, but when I go to deploy the web app to the server, I want it to include the username and password for another web service which it connects to. If I enter the settings manually in IIS on the server, they are lost each time I publish the app.
If I omit the keys in the appSettings block in my web.config (so that they are only referred to in the secrets file), the manually-entered settings in IIS on the server are removed completely whenever I publish the app.
Being able to refer to certain things in an external file for the sake of better security and not checking in passwords to source control isn't turning out to be a very good idea IMHO because my deployment is now a nightmare. I don't want to manually enter the passwords in the web.config file on the server after every deployment.
I'd rather not look into encryption, either, because I would have to do that for each server I deploy to so that the relevant machine key is used for each web.config file.
I've only recently thought about removing this password from source control, in response to a recent push to improve security practises at work - which I well understand and agree with - but I can also see why security is so poorly considered because the life of the ordinary developer becomes extremely unpleasant if there the tools available don't make it easy.
Surely there's a way without resorting to encryption?
Thanks.
Without a CI system I think your best option is probably a pre/post build action that executes a script?
I'd suggest you replace the actual values with tokens for your sensitive web.config values (something unique/easy to find like MY_PRODUCT_DATABASE_PASSWORD etc). Your web.config can then be checked into source control safely.
In VS you can add a build action to run a custom powershell or exe to basically perform a find-and-replace on the tokens with actual values before you zip & deploy as normal.
Exactly how/where you store the real values and how the script works is up to you. you could easily find a file on your deployment machine or a row in some database based on data passed to the script/exe from vs or from data within web.config itself (or embedded as a comment in web.config even).
Here's details of the variables available from vs you could pass to your exe or script in a build action: https://msdn.microsoft.com/en-us/library/42x5kfw4.aspx
It you wanted to use PowerShell you could read/replace/write values to a web.config(or any text file) like this answer: How can I replace every occurrence of a String in a file with PowerShell?
Following the Microsoft Docs example you've linked to, putting this XDT transformation inside Web.Release.config should do the trick:
<appSettings file="..\..\AppSettingsSecrets.config" xdt:Transform="SetAttributes">
<add key="mailAccount" xdt:Locator="Match(key)" xdt:Transform="Remove" />
<add key="mailPassword" xdt:Locator="Match(key)" xdt:Transform="Remove" />
<add key="TwilioSid" xdt:Locator="Match(key)" xdt:Transform="Remove" />
<add key="TwilioToken" xdt:Locator="Match(key)" xdt:Transform="Remove" />
<add key="TwilioFromPhone" xdt:Locator="Match(key)" xdt:Transform="Remove" />
<add key="GoogClientID" xdt:Locator="Match(key)" xdt:Transform="Remove" />
<add key="GoogClientSecret" xdt:Locator="Match(key)" xdt:Transform="Remove" />
</appSettings>
You dont need xdt:Locator attribute on <appSettings> element itself, because there is only one appSettings.
Edit: I've misunderstood the original question. The goal is to include contents of referenced file, which is not possible using XDT. There has to be another way.
In asp.net we can include file attribute in appsettings that can contain secret values:
Web.config
<appSettings file="HiddenSettings.config">
</appSettings>
HiddenSettings.config
<?xml version="1.0"?>
<appSettings>
<add key="DbConnectionString" value="VALUE_IN_TEMPLATE_FILE" />
</appSettings>
In git, we can simply keep the HiddenSettings.config in git-ignore, so that sensitive information will not be checked-in.
The problem with this approach is every time the developer takes the first copy of the code, he/she needs to fill the secret data manually.
What's the best practice to do that automatically (i.e. no manual action to fill secret information in local/target deployment environment)?
I've been pondering that recently myself. The best method I could come up with so far is to link to a separate config file as you did and put that file to a separate private repository. Then add that repository as a submodule to the actual project. For instance:
git submodule add git#github.com:someUser/private-config.git
and the config points to the relative path of the submodule, something like:
<appSettings file="../../../../private-config/The.Real.Deal.config">
<add key="someKey" value="SAMPLE VALUE" />
</appSettings>
So when a user checks out the project (with initializing submodules) the config in the private-repo will be available. If not than they can download the project without the actual values and will only have access to the sample values.
Compared to other methods this looked good to me but I'm always open to suggestions too.
Is it possible to add Application Insights to a Web Site project type?
In Visual Studio, the following context menu is available for Web Application projects but is missing for Web Site projects.
You should be able to instrument a Web Site project with Application Insights manually. Here are the instructions.
Just want to share what I ended up with doing. First of all, it seems to work like a charm.
The Application Insight is implemented as an ASP.NET Module, so in order to hook it up for Web Site project you need to do the following:
Add Microsoft.ApplicationInsights.Web NuGet package
Register AI module in web.config
<modules runAllManagedModulesForAllRequests="true">
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition="managedHandler" />
</modules>
Make sure you have ApplicationInsights.config in Web Site base directory (along with web.config) - it defines which telemetry you going to be collecting
I use Visual Studio for Website development (VS 2010 Ultimate and VS 2012 Professional). To be more specific, I created this website by File > New Web Site, so I do not believe this is a project.
While developing the website, I have debug="true" enabled in the web.config file. When I publish, I manually change to debug="false".
<configuration>
<system.web>
<compilation debug="true" strict="true" explicit="true" targetFramework="4.5">
</system.web>
</configuration>
There are two config files in the solution: "web.config" and "web.Debug.config".
This is what the various forum articles and "Programming ASP.NET" books say to do, but I wonder if there is a way to have debug="true" for local development and automatically switch to debug="false" when using Build > Publish Web Site so I don't have to manually change the web.config file?
According to this forum answer, "There is no way to have a Release configuration for your website."
Keeping in mind that this is a Web Site and not a project, it looks like adding another config based on comment suggestions might not be possible. A possibly valid answer is "no, it is not possible in this context."
Is there another way to achieve the intended outcome without using the current workaround of manually changing the debug setting?
Sorry, it's related to it being a "web site" type project, which aren't compiled:
Configuration of publishing an ASP.NET web site
To quote the previous responder above:
"Web Site projects don't have the Release configuration available, but it makes no difference since they are not compiled. Web Application projects, on the other hand, do get compiled and have both configurations available."
According to the available references, for "ASP.NET Website" it is not possible to have a separate release configuration.
So the answer to the posed question is no: it is not currently possible. Manually changing the debug attribute when you publish and then changing it back is the only option in that case.
How can you proceed? If you really need to have a release configuration and a debug configuration, the a possible option is Converting a Web Site Project to a Web Application Project. While not a direct answer to the presented question, it is an alternative.
For some projects I've set up an Environment appSetting and scoped all other keys off of that Environment.
For instance:
<add key="Environment" value="Development"/>
<add key="Development.Title" value="My Dev App"/>
<add key="Production.Title" value="My Production App"/>
<connectionStrings>
<add name="DbContext.Development" connectionString="Initial Catalog=DatabaseDev;...."
providerName="System.Data.SqlClient" />
<add name="DbContext.Production" connectionString="Initial Catalog=DatabaseProd;...."
providerName="System.Data.SqlClient" />
</connectionStrings>
Then you would create a Configuration class that would pull appSettings and connectionStrings by looking for:
appSetting
string.Format("{0}.Title", ConfigurationManager.AppSettings["Environment"])
connectionString
string.Format("DbContext.{0}", ConfigurationManager.AppSettings["Environment"])
Not perfect but this will let you only have to replace one web.config value instead of a bunch without the help of the Publish config transform.
In our system most of the code is in an asp.net (2.0) web site, I discovered Castle Monorail a few month ago and I think it's really easier to use than asp.net / webforms.
Here is what we need :
- Use Castle Monorail
- Our code must be in the website (my chief is a kind of old school web developer so he prefer to have some ".cs" files than one ".dll").
- We have to keep the existing webforms code
So maybe if you have a tutorial or something like that (I found a lot of tutorial about asp.net MVC and castle monorail but I did find any with asp.net 2.0)/
Merci les collegues
So it was pretty simple (15 min top) :
1/ Get the element that you need from web.config :
- config section handler
<section name="monorail" type="Castle.MonoRail.Framework.Configuration.MonoRailSectionHandler, Castle.MonoRail.Framework" />
-Configuration itself
<monorail>
<controllers>
<assembly>App_Code</assembly>
<assembly>Castle.Monorail.ViewComponents</assembly>
</controllers>
<viewEngines viewPathRoot="Views">
<add type="Castle.MonoRail.Framework.Views.NVelocity.NVelocityViewEngine, Castle.MonoRail.Framework.Views.NVelocity" />
</viewEngines>
</monorail>
"App_Code" is the name of the web site assembly.
-http handlers
<add verb="*" path="*.rails" type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, Castle.MonoRail.Framework" />
<!--block direct user access to template files-->
<add verb="*" path="*.vm" type="System.Web.HttpForbiddenHandler" />
<add verb="*" path="*.boo" type="System.Web.HttpForbiddenHandler" />
<add verb="*" path="*.st" type="System.Web.HttpForbiddenHandler" />
-http modules
<add name="monorail" type="Castle.MonoRail.Framework.EngineContextModule, Castle.MonoRail.Framework" />
2/ Take the dll that you need, in my case (I don't use activerecord) :
Castle.Components.Binder.dll
Castle.Components.Common.EmailSender.dll
Castle.Components.Common.TemplateEngine.dll
Castle.Components.Common.TemplateEngine.NVelocityTemplateEngine.dll
Castle.Components.Validator.dll
Castle.Core.dll
Castle.MonoRail.Framework.dll
Castle.MonoRail.Framework.Views.NVelocity.dll
Castle.MonoRail.ViewComponents.dll
3/ Add a class in your App_Code folder (for instance TestMonorailController) :
using Castle.MonoRail.Framework;
public class TestMonorailController : SmartDispatcherController
{
public TestMonorailController()
{
}
public void OnePage()
{
PropertyBag["toto"] = "TEST";
}
}
4/ Add a Views folder in the root of your website
5/ Add a TestMonorail folder in the folder you just created
6/ Add a file name "OnePage.vm" in this folder :
$toto
7/ Test your website :
http://localhost:XX/YourWebSite/TestMonorail/OnePage.rails
and you should see
"TEST"
Et voila :) I can edit my production code. Thx Ken
I guess that you could put the controller classes in App_Code and be done with it.
you will need to map a special extension for Monorail urls.
If you do not use SOAP webservices (.asmx) then map this extension to Monorail's HttpHandlerFactory.
An interesting culprit could be that the actual assembly containing the App_code files does not have a nice name (I think), and MonoRail does need to know the assembly from which to locate controller classes.
I'd suggest you play with the hints I've listed above and see where it gets you. Share the exceptions you see and hopefully we'll get to the bottom of it soon