I'd like to run a local NuGet Gallery to serve dependencies to my build system.
I notice in the web.config it asks for Azure details, but the code seems to suggest you can choose 'FileSystem' as a storage backend.
My questions are:
If I choose 'FileSystem' how do I configure the target folder?
Can I instead point the storage engine at an in-house instance of SQL Server?
I'm trying to avoid using a file system because that's what we are using now with NuGet Server and it's very slow. A couple of the devs like to pack and push every single successful build, so scalability is important.
I hope any answers here will help others, too. For background, here is a great link of setting up your own NuGet Gallery. Sadly, the author has omitted all details pertaining to the actual package storage: https://github.com/NuGet/NuGetGallery/wiki/Hosting-the-NuGet-Gallery-Locally-in-IIS
To configure File System Package Store:
<appSettings>
<add key="Gallery:PackageStoreType" value="FileSystem" />
<add key="Gallery:FileStorageDirectory" value="C:\Path\To\Packages" />
</appSettings>
To point to a different SQL Server:
<connectionStrings>
<add name="NuGetGallery" connectionString="Data Source=SQLSERVERNAME;Initial Catalog=NuGetGallery;Integrated Security=SSPI" providerName="System.Data.SqlClient" />
</connectionStrings>
EDIT: Support SQL Server as Package Store
If you want to store your packages as BLOBs in SQL Server, you'll have to make a couple of changes to the code.
First, create a class named SqlServerFileStorageService and implement IFileStorageService. This interface has several methods. The important ones are GetFile() and SaveFile(). Combining folderName and fileName will create a unique key you can use in your database table.
You can use the same connection string NuGetGallery or add a new one for your data access.
You then add an item to the enum PackageStoreType called SqlServer.
In ContainerBinding.cs add a case for PackageStoreType.SqlServer to bind to your SqlServerFileStorageService.
Now the NuGet Gallery should create a SqlServerFileStorageService and all gets and saves will use your class to store the blob in SQL Server.
BTW: I'm basing this on a cursory look at the code. There may be an extra step or two, but these look like the main areas you'll need to focus on.
Hope that helps.
Related
I using Entity framework and sqlite to my project.
when I setup my project I don't know to change my connectionstring :
<connectionStrings>
<add name="mainEntities"
connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model
1.msl;provider=System.Data.SQLite.EF6;
provider connection string="
data source=C:\Users\Nam\Desktop\ConsoleApp\ProductDB.db""
providerName="System.Data.EntityClient" />
</connectionStrings>
so I decided to let it stay here (not change)
and after setup I can't open my app. My database ( .db) stay from another file
( not in my project ).
I saw many videos on youtube but It mostly using ADO.NET .
Plaese help me code to change connectionstring and all above is the way can create file .db in my project.
thanks guy .
You need to install a SQLite Data provider, then you will be able to add a SQLite database datasource trough the VS wizard (it will create the connection string).
Follow this steps for details:
https://github.com/ErikEJ/SqlCeToolbox/wiki/EF6-workflow-with-SQLite-DDEX-provider
I've been using Replace Tokens (from VS Marketplace) and it served me well so far for the dynamic connection string substitution in the web.config file. The way it works, in the Web.Release.config I have a construction like this:
<connectionStrings>
<add name="Default"
connectionString="__AzureDBConnectionString__"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
When I start release in VSTS, it replaces this token (in between "__") with the variable value in the release pipeline. So, I always have a connection string that corresponds to the relevant environment.
Yesterday I decided to add some more variables into this file, hoping it'll work as well, as I have a lot keys that should be parametrized for security reasons.
Well, if I add to the file something like this:
<appSettings>
<add key="mailToken" value="__mailToken__" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
</appSettings>
it doesn't work. In the web.config which is deployed, I see value="mailToken" i.e. it's not substituted with the variable stored in the release pipeline (as for connection string).
After around a day of suffering, I discovered that the only parameter that could be replaced like that is connection string (because this is the only parameter set in auto-generated by the build "Web.SetParameters.xml" file). I tried to play around parameter.xml file as some sources suggest, but no success. It is important that all the variables are taken from the release pipeline variable list (and not hardcoded in config files).
Can someone suggest a proper way to substitute the values in appSetting or another workaround (without Replace Tokens task etc.)?
According to your description, you are using Web Deployment Package (Web.SetParameters.xml), by default the appSettings in Web.Release.config won’t be added to Web.SetParameters.xml file, but will replace the value in web.config file directly when generate the Web Deployment package, so the value of mailToken in web.config file (in zip package file) will be mailToken.
So, the simple way to replace it is using XML variable substitution in File Transforms & Variable Substitution Options section of IIS Web App Deploy or Azure App Service Deploy task. You just need to add the variable with the same name of key value (mailToken) to the release definition and check the XML variable substitution option. (Do not need to configure it in Web.Release.config)
More information, you can refer to: XML variable substitution
I struggled with something similar recently too, only today did I come to a solution. My main hangup was defining the parameters.xml file in my project directory, as this conflicted with some of the auto replacement logic defined in the vsts-tasks release task for web deploy. I'd only define parameters.xml for properties that won't be handled automatically through VSTS.
Also, I'd suggest adding this msbuild parameter to your build job under "Build Solution", this will prevent VSTS from adding connection strings in the setparameters.xml file of your web deploy package.
/p:AutoParameterizationWebConfigConnectionStrings=false
Ultimately if this doesn't work, you'll want to turn on System.debug to true in your environmental variables so you can see exactly what is going on during release. Unfortunately the debug logging you'll see with system.debug on aren't that great, but they may help.
Good luck!
I'm getting the following error:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
I've just created my first ever EF project. It's an MVC app and I added the entity model in the MVC project. I also added a DataAccess class and a class for running tests using NUnit. Eventually, I'll add a service class which will reference the DataAccess class. So, the code currently looks like this (I'm just trying to get a test working to prove EF is doing its thing):
Text Fixture calls DataAccess class
DataAccess class calls Entity Framework
Entity Framework accesses a local database
For the time being, I'm just trying to return all rows/one column from one table. Remember, all these files are in a single project. I've read quite a lot that this problem stems from having multiple projects, but that doesn't seem to apply in my case. I've checked in the "main" web.config file. The connection string looks okay. I copied that same config section (i.e., connectionStrings) into the Debug-specific config file, too, but that didn't make a difference. Any ideas why I'm seeing this error?
Thanks,
Jay
Connection strings:
This is the connection string from the dialog box when creating the Entity Access file (data source is a period in both strings [i.e., local host]):
metadata=res:///EntityDataModel.csdl|res:///EntityDataModel.ssdl|res://*/EntityDataModel.msl;provider=System.Data.SqlClient;provider
connection string="Data Source=.;Initial Catalog=URIntake;Integrated
Security=True"
This is the connection string from the web.config file. They seem the same, for all practical purposes:
metadata=res:///EntityDataModel.csdl|res:///EntityDataModel.ssdl|res://*/EntityDataModel.msl;provider=System.Data.SqlClient;provider
connection string="data source=.;initial
catalog=URIntake;integrated
security=True;multipleactiveresultsets=True;App=EntityFramework"
Microsoft Zlatko Michailov Says,
app.config is not in the binary directory where the exe is. Please do
the following:
Visually verify that the app.config with the expected content is in the directory where the exe is compiled. (Existence in the project
root directory is not enough.)
Use System.Configuration.ConfigurationManager from within your app to examine the content of the app.config your exe is using.
I’m also looking at the content of the connection string, and I can say
that it may not work in a multi project environment (unless you’ve
duplicated the EDM in each project).
The reason for that is “.”
resolves to the directory where the exe is loaded from. If you want to
reuse the same EDM, you at least have to make a few steps back in the
path and then navigate to the project where the EDM is, e.g.
“......\Proj1\AdventureWorksModel”.
Additionally you may consider
using the |DataDirectory| macro - when you load an AppDomain you can
set |DataDirectory| to point to the exact directory where the EDM is,
and then use that in the connection string, e.g.
“|DataDirectory|\AdventureWorksModel”.
If you are working on an
ASP.NET project, you can use “~” which refers to the project root. In
that latter case, you can’t reference a model outside your project’s
hierarchy though.
For more information Check Here
UPDATE 1 :
Here you can try below mentioned steps
Clear connection string content on the web.config file like below
Then Remove your *.edmx file from your project
Recreate it again like below (sample one).Don't forget to tick the "save entity conncetion settings in web.config as :"
Final Step : After that go to the web.config file and check whether your connection string is exactly the same as on which showed on "Entity Connection String :" as above step(I showed it on red mark above image).
I hope this will help to you.
To deploy to different azure environments I modify the csdef as part of the compilation step to change the host headers. Doing so requires building the cspkg once for each environment instead of being able to reuse the cspkg and specify different configs for deployment.
I would like to instead modify the csdef file of a cspkg after it has been created, without recompiling. Is that possible, and if so how?
I've done something similar to what you're after to differentiate between test and live environments. First of all you need to create a new .csdef file that you want to use for your alternate settings. This needs to be the complete file as we're just going to swap it out with the original one. Now we need to add this to the cloud project. Right click on the cloud project and select unload project. Right click on it again and select Edit [Name of project]. There's a section that looks a bit like this:
<ItemGroup>
<ServiceConfiguration Include="ServiceConfiguration.Test.cscfg" />
<ServiceDefinition Include="ServiceDefinition.csdef" />
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
</ItemGroup>
Add a new ServiceDefinition item that points to your newly created file. Now find the following line:
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
Then add this code block, editing the TargeProfile check to be the build configuration you're wanting to use for your alternate and ensuring that it points to your new .csdef file
<Target Name="AfterResolveServiceModel">
<!-- This should be run after it has figured out which definition file to use
but before it's done anything with it. This is all a bit hard coded, but
basically it should remove everything from the SourceServiceDefinition
item and replace it with the one we want if this is a build for test-->
<ItemGroup>
<!-- This is an interesting way of saying remove everything that is in me from me-->
<SourceServiceDefinition Remove="#(SourceServiceDefinition)" />
<TargetServiceDefinition Remove="#(TargetServiceDefinition)" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' == 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.Test.csdef" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' != 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.csdef" />
</ItemGroup>
<ItemGroup>
<TargetServiceDefinition Include="#(SourceServiceDefinition->'%(RecursiveDirectory)%(Filename).build%(Extension)')" />
</ItemGroup>
<Message Text="Source Service Definition Changed To Be: #(SourceServiceDefinition)" />
</Target>
To go back to normal, right click on the project and select Reload Project. Now when you build your project, depending on which configuration you use, it will use different .csdef files. It's worth noting that the settings editor in is not aware of your second .csdef file so if you add any new settings through the GUI you will need to add them manually to this alternate version.
If you would want to just have a different CSDEF then you can do it easily by using CSPACK command prompt directly as below:
Open command windows and locate the folder where you have your CSDEF/CSCFG and CSX folder related to your Windows Azure Project
Create multiple CSDEF depend on your minor changes
Be sure to have Windows Azure SDK in path to launch CS* commands
USE CSPACK command and pass parameters to use different CSDEF and Output CSPKG file something similar to as below:
cspack <ProjectName>\ServiceDefinitionOne.csdef /out:ProjectNameSame.csx /out:ProjectOne.cspkg /_AddMoreParams
cspack <ProjectName>\ServiceDefinitionTwo.csdef /out:ProjectNameSame.csx /out:ProjectTwo.cspkg /_AddMoreParams
More about CSPACK: http://msdn.microsoft.com/en-us/library/windowsazure/gg432988.aspx
As far as I know, you can't easily modify the .cspkg after it is created. I guess you probably technically could as the .cspkg is a zip file that follows a certain structure.
The question I'd ask is why? If it is to modify settings like VM role size (since that's defined in the .csdef file), then I think you have a couple of alternative approaches:
Create a seperate Windows Azure deployment project (.csproj) for each variation. Yes, I realize this can be a pain, but it does allow the Visual Studio tooling to work well. The minor pain may be worth it to have the easier to use tool support.
Run a configuration file transformation as part of the build process. Similiar to a web.config transform.
Personally, I go with the different .csproj approach. Mostly because I'm not a config file transformation ninja . . . yet. ;) This was the path of least resistance and it worked pretty well so far.
I'm sure everyone has to deal with these situations, we check in our solution to source control and each dev machine will have its own resources for debugging, building and testing..
The most common being:
Web server (IIS)
Database (SQL)
The web server is easy to handle, each dev machine will have its own proj.user file to specify different debug information.
But connection strings for the app are stored in the web.config (which is under source control), ideally we don't want the web.config to be 'aware', so having to do config sections where we delegate them to other config files (not under sc) wouldn't be the best solution..
asp.net (.net?) already supports a model to have web.config inheritance, which would be an ideal scenario.. however this only works for directories.
It would be great if we could have
web.config <-- under version control
web.machine.config <-- not under version control
Of course I'm open for better suggestions of how people solve this problem.
Like.. maybe having:
web.base.config <-- under version control
web.machine.config <-- not under version control
And having a build script that creates a web.config by merging them?
Thanks in advance,
Stephen.
edit
Looks like the next vs may have a way to handle this:
http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
edit edit
Possibly do'able with xml mass update today:
http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx
edit edit edit
Well its certainly possible to do with a simple xslt build task and a small transform that copied everything and intercepts certain properties.. just tried a proof of concept and this will save us lots of frustration, but the transformation file may be more than people are willing to accept.
Basically we store a Web.base.config in version control, and run it through the transform to generate the Web.config on a build event.
Seems like vs2010 will really help in terms of having a much more friendly version of this.
One approach that I sometimes use is to break out environment-specific section into separate config file, that are usually excluded from deployment (except for the first time or if their structure change):
Example for connection strings:
In web.config:
<connectionStrings configSource="connections.config"></connectionStrings>
The connections.config file (that is typically not included in the deployment; so it is unchanged):
<?xml version="1.0"?>
<connectionStrings>
<add name="connectionName" connectionString="[connection string goes here]"/>
</connectionStrings>
Like that we have created an "incapsulation" of the information, and can easily deal with issues like source control, deployment and such of that information.
Whilst there are certainly plenty of solutions, none of them really give you a huge amount of control over the generated configuration, one solution that I noted in my edit where you get a huge amount of control but with the overhead of having to write an xslt file, was using an xslt build task to use the template web.config/app.config from source control (which I personally name web.base.config/app.base.config), and use an xslt file to transform the version controlled config file at build time, and generate a web.config/app.config.
Here is an example of an xslt build task (although you may want to write it to your own coding standards), and an example of a mundane xslt transform that will change the value of a connection string and copy everything else in the config:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
<xsl:output method="xml" indent="yes"/>
<!-- Copy all. -->
<xsl:template match="#* | node()">
<xsl:copy>
<xsl:apply-templates select="#* | node()"/>
</xsl:copy>
</xsl:template>
<!-- Swap connection string. -->
<xsl:template match="/configuration/connectionStrings/add[#name='my_connection_string_name']">
<xsl:copy>
<xsl:apply-templates select="#* | node()"/>
<xsl:attribute name="connectionString">my replacement connection string value</xsl:attribute>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
This is a mediocre example, but you can imagine you can completely transform entire sections where you previously would struggle with an inheritance based scenario.
VS 2010 will provide you with a lot of control to manage web.config files for various configurations... Please check out.
The configuration of an application can be split into two categories.
Application specific
Deployment specific
Application specific configuration includes things like caching implementation, business rules implementation, and will apply to every deployment of the application. This should go into the web.config file that is part of the application directory structure and is checked into source control.
Deployment specific configuration includes things like connection strings, timeout periods, etc, and may differ from one deployment to another. This should be entered as part of the configuration of the IIS instance that is involved in the deployment and preserved by whatever backup strategy is in place for the machine in question.
As far as I can tell, this is exactly what the hierarchical nature of the web.config files was designed to handle.
The advantages of such an arrangement are...
No need to worry about which developer's version of the settings end up in source control, because none of them do.
Every deployment uses the same binary, so deployment issues are more likely to involve the deployment configuration.
Subsequent deployments should need no deployment specific configuration changes, because they are already in place.
We don't store environment settings in the web.config.
They're stored in a database.
This enables us to do xcopy deploys, and to store the web.config file in our version control system.
Access to the database is via one registry key.
What you're describing sounds a lot like using a Machine.config file to store connection strings. I haven't seen this mentioned yet, so have you tried it? It looks like you can use a global Web.config that sits beside your Machine.config as well.
A few links:
ASP.NET Configuration File Hierarchy and Inheritance
Difference between Web.config and Machine.config