which files should be added to Souce Control (Service Reference) - asp.net

When i added service reference to my .Net project (right click->Add Service Reference), VS created a folder with the Service name and created bunch of files (listed below). I am not sure which files should be added to the source control so that next time when i upgrade the service reference, i dont end up deleting some files and adding new files. List of files that VS created in the service folder are as below:
ConfigurationService.disco
ConfigurationService.wsdl
ConfigurationService.xsd
ConfigurationService1.xsd
ConfigurationService2.xsd
ConfigurationService1.wsdl
ConfigurationService3.xsd
ConfigurationService4.xsd
configuration91.svcinfo
configuration.svcinfo
Reference.svcmap
Reference.cs
abc.datasource
def.datasource
ghi.datasource
jkl.datasource
mno.datasource
pqr.datasource

usually we add the whole folder with all its files, you can safely do that.
user specific files are not created in that subfolder.
Consider that when you will update the reference some files will be edited and others will not be touched. If some are fully regenerated TFS or the source control system you are using will get the changes, not the deletion and re-add as another file with same name; at least I would expect so and never seen anything different happening.

Related

Is it necessary to recycle app pool in order to refresh cached query plans?

I'm not sure if I'm asking the right question exactly, but if you know the answer then you'll probably understand what I'm asking.
I updated a stored proc and tested in dev w/ no problem. So then I updated the proc in production and it caused errors. Took me a bit to figure out what was going on because all I changed was a field in the select list from i.Price to Price = coalesce(r.Price, i.Price). Eventually I figured the only difference could be that r.Price is a decimal value whereas i.Price is a money value so the return type of the field had changed.
Normally that shouldn't matter for c# code. the DataReader value gets cast to decimal either way just fine. But all I had to do to fix the error was reset the app pool and then it worked. I believe I could have also updated my query to cast to a money type and that probably would have worked as well.
I know I've run into this kind of issue a few times before, enough to know there's some kind of caching going on under the hood in asp.net and/or the sql assemblies.
My question is, how can I get this cache to refresh without recycling the app pool. Or is that the only way?
Here what exactly happens when you deploy :
ASP.NET has a feature called shadow copying that enables assemblies that are used in an application domain to be updated without unloading the AppDomain. Normally, this is required because the Common Language Runtime (CLR) will lock the assemblies so you can’t just copy a new assembly over it. Shadow copying means that the original assembly is copied to a temporary location. The copied assembly is locked, and the original assembly can be updated with a new version.
What is assembly interning?
From :
From MSDN:
The ASP.NET shadow copy feature enables assemblies that are used in an application domain to be updated without unloading that AppDomain (necessary because the CLR locks assemblies that are being used). This is done by copying application assemblies to a separate location (either a default CLR-determined location or a user-specified one) and loading the assemblies from that location. This allows the original assembly to be updated while the shadow copy is locked. ASP.NET turns on this feature by default for Bin folder assemblies so that DLLs can continue to be updated while a site is up and running.
https://msdn.microsoft.com/en-us/magazine/hh882452.aspx
App Pool will be recycled automatically when below happens:
Any modifications in the Application’s BIN Directory
Making changes in any Configuration File/s, like Web.config or others ( if you have any specific config file in your application say in a directory called App_Config).
Making modifications in the Source code files in APP_CODE Directory. This maybe change in any Source code files, or adding or deleting files from this directory.
Making changes in the Global.asax file
Making Changes in the Machine.config file.
Making any modifications in the Web Application’s Root Directory. This means creating files/subdirectories on the fly can lead to application pool recycling.
Modifications for references of Web Services of App_WebReferences directory.
Modifying the Security Settings of any directory in the Root directory. (Like specifying read security rights for everyone or any other specific user or user group.)
For more details :
Does any change in any file inside bin folder cause application recycle in ASP.NET web application?

Dynamic database reference in SSDT (dacpac) project

Is there a way where the database references in a SQL Server Database project (Dacpac) can be derived at run time?
We're building a product which uses Dacpac to deploy database objects.
Our product implementation teams also use Dacpac projects by adding database reference to the product Dacpac file and then adding their own additional objects to the project.
The problem we're facing is - every time the implementation needs to point to a newer product release version, the parent dacpac references in the implementation dacpac have to be changed manually to refer to the new file path of the new product dacpac (in the newer release). We've mutiple implementation teams and multiple database projects in each implementation.
Is there any way the database references (*.dacpac) in a database project can be derived at run time using a variable or parameter or something of that sort?
My understanding of your question is as follows:
You have a SSDT database project (see example image below), that has a database reference (similar to #1 below) with stored procedures and other db objects that access the reference database (similar to file #2 and code #3). You've 'built' the solution resulting in a DACPac and now you want to take this DACPac and reference other databases at deploy-time. Hopefully I understood your question correctly.
If so, then you can use the Publish Profiles feature to achieve this (similar to #4 below).
The code for this can be seen in my notes from my SSDT talk github project.
If you look specifically at the demo04 solution file, you will see that I have a DEV_MJE.deploy.ps1 PowerShell file and a DEV_MJE2.deploy.ps1 file. These scripts run MSBuild to build the DACPac and then use SqlPackage to publish DEV_MJE.publish.xml or DEV_MJE2.publish.xml respectively. Note, if you run this example on your machine, you'll need to add MSBuild.exe and SqlPackage.exe to your path, as well as modifying the TargetConnectionString in the xml files to an existing development database.
As an example of how this works...When I use the Publish Profile DEV_MJE.publish.xml, the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE].[dbo].[AnotherTable]
Whereas when I use DEV_MJE2.publish.xml the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE2].[dbo].[AnotherTable]
Notice the database reference in the second has changed to AnotherDb_MJE2.
For a good description of how Publish Profiles relate to DACPacs and SSDT Database Projects, see this web page. It also contains information on alternative ways to deploy beyond SqlPackage.exe.
Something else to consider
Note, that using file paths to version control a DACPac is not really the best practice. Consider the DACPac artifact as similar to a .Net DLL. It is the biproduct of a build.
As such, a better approach is to use NuGet and tools like Octopus Deploy to store, track, and deploy DACPacs. See the stackoverflow answer for a good description of how this works.
Hope that this helps,
Michael
Thanks for the followup comment, I think what you are trying to do is when you write and deploy your code be able to use different dacpacs depending on the project?
Each implementation team might have a different version of the shared dacpac deployed so you can't just put the files in a shared location and call the dacpac "Product_Latest.dacpac" or something, so everyone always gets the latest version.
".sqlproj" files are standard msbuild scripts and references can be managed using msbuild properties so you can technically change the reference at runtime. If you edit your .sqlproj file and add a property in the first <PropertyGroup> tag, I used:
<ProdDacpacVersion Condition="'$(ProdDacpacVersion)' == ''">v1</ProdDacpacVersion>
v1 is the unique name for the version folder - you just need something to identify the dacpac you want.
I put the property just after TargetDatabaseSet and IncludeCompositeObjects.
If you then find the reference to the dacpac and instead of
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\v1\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\v1\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Use the property from above:
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Then the reference will use the property to get the path of the dacpac. There are a few ways you can set the property, you could edit the .sqlproj file when you want to take a new version of read the property from a file or environment variable or something (i'll leave the msbuild fun to you!).
I would, as a standard, everytime the reference was changed either reload the project or restart visual studio - it won't take long and it will save lots of cursing :)
When you deploy the dacpac's, the deploy looks in the same folder for references first so just make sure you copy the right one into the bin folder when you deploy.

What is Newtonsoft.Json.xml? [duplicate]

I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.

MSBuild/WebDeploy - How to prevent it from deleting a folder and its contents

We're using TeamCity to automate MSBuild to use WebDeploy to push our application to our various servers.
For the most part, we've got this working, and great. One snag, though: we've got a folder that holds uploads that we don't want to have deleted during the publication.
How do I tell WebDeploy, "I know that folder's not in the compiled application. Ignore it. Just leave it alone."
If you're using the dirPath, filePath, or contentPath providers, you can specify the DoNotDelete rule to block deletions of files on the destination computer that do not exist on the source. The syntax to add to the command line would be -enableRule:DoNotDelete. For more information, see the provider articles mentioned and Web Deploy Rules.

WiX (Votive) Project Reference Harvesting (HEAT) an ASP.Net Web Application

What I'm Doing
I have an ASP.Net Web Application and a WiX Setup Project in Visual Studio 2010. I can explicitly harvest the web application with the following HEAT command set as a pre-build event for the setup project:
“%WIX%\bin\heat.exe” project "$(SolutionDir)Application.WebUI\Application.WebUI.vbproj" -o "$(ProjectDir)ProjectOutputContent.wxs" -pog Content -ag -template fragment -nologo -directoryid RUNTIMEFOLDER
“%WIX%\bin\heat.exe” project "$(SolutionDir)Application.WebUI\Application.WebUI.vbproj" -o "$(ProjectDir)ProjectOutputBinariesAndSymbols.wxs" -pog Binaries -pog Symbols -ag -template fragment -nologo -directoryid BINFOLDER
Keep in mind that RUNTIME folder and BINFOLDER are directories I declaratively setup in my main product WXS file.
Why I Don't Like It
This approach is annoying because I need the HEAT generated fragment WXS files checked out before I can build the setup project. Another consideration is that it is a web application and I need to drop the binaries and symbols into a different directory (bin) than the content.
What I'm Aiming For
I would rather use a project reference within the Wix Setup Project and simply set the Harvest property to True. I could then harvest the BinariesContentSatellites to get the items I need in my fragment and then set a single Directory Id that I can reference in the main product WXS. The problem is that this will put the content, binaries and symbols in the same folder where I need the latter two in a nested bin folder. I can't add this project reference twice, each with different harvest options.
My Question
Is there a way to do what I'm after or do I need to keep with the pre-build event? As an aside, I have considered manually harvesting the fragment once, without a build event, and then re-harvesting as needed. I would prefer to avoid that approach.
Answering your topic "Why I Don't Like It" : I too had same problem but then i found the solution. You dont need to check-in the fragment file. Just add the file physically and then include in your project
Note : Don't add the fragment file from the project.

Resources