I've been attempting to fix a problem I have with Test Explorer not showing tests when I'm in a different configuration environment. I make local environment changes by updating my app.config.
I have already tried a few steps found here and in other sites including cleaning my project, updating to the latest xUnit test runner, etc.
I am sure the reason is code/project based and not the Visual Studio environment itself. What I would like to know is whether or not there is a log file I can look at that would help me to determine why my tests are not showing. Or, is there another good method to troubleshoot errors with tests not showing up in Test Explorer?
There is a MSDN Blog post about this.
Essentially, you need to:
Go to folder %VSInstallDir%\Common7\IDE\CommonExtensions\Microsoft\TestWindow
Find the config file for the process you want to debug (e.g. vstest.console.exe.config, vstest.discoveryengine.exe.config, etc)
Alter the config file system.diagnostics node to include:
<system.diagnostics>
<switches>
<add name="TpTraceLevel" value="4" />
</switches>
</system.diagnostics>
Close VisualStudio, open it again, and discover/run tests from TestExplorer Window
Look for logs under %temp%[processname].TpTrace.log (e.g. vstest.console.tptrace.log)
Related
After installing Visual Studio Enterprise 2017 (Version 15.1 (26403.7)) my Azure Cloud Service does no longer build and gives me the 'Error WAT200: No default service configuration "ServiceConfiguration.cscfg" could be found in the project'. Although it still works fine with Visual Studio Enterprise 2015. (The right TargetProfile is also specified...)
I ran into this last night.
It actually happens when you rename Cloud Service configurations away from Cloud and Local.
In my case, I had deleted the Cloud configuration and created a new, differently named one.
By ensuring that the configurations are called Cloud and Local, the Cloud Service projects will build again using "Resharper build", and (most likely) under "Lightweight solution load".
The configurations can be renamed by right-clicking one of the service roles under the Cloud Service node in Solution Explorer, choosing Properties, then opening up the "Service Configuration" dropdown and clicking <Manage...>.
Now, in the resulting dialog, the configurations can be renamed:
The following bug report got me on the right track:
https://youtrack.jetbrains.com/issue/RSRP-450390
The best way is to change the service configuration prefix in ccproj of your project, add yourprojectname.configurationname
Dot is the life saver.
<ServiceConfigurationPrefix>yourproject.ServiceConfiguration</ServiceConfigurationPrefix>
Add these in itemgroup:
<ServiceDefinition Include="yourproject.ServiceDefinition.csdef" />
<ServiceConfiguration Include="yourproject.ServiceConfiguration.cscfg" />
Make sure you have renamed your cscfg files from the folder it resides.
Reload
Bingo. It works.
Ok I found it, after disabling the 'Lightweight Solution Load' (which in VS 2017 u can disable by right click on the Solution and then Disable Lightweight Solution Load), the error disappears and the Cloud Service builds again.
Similar to Rishikesh mentioned, but I added a service config entry
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
to the ccproj. Then copied a configuration, e.g. Production and named it ServiceConfiguration.cscfg. Then reloaded the project. That got the ReSharper to build, but MORE importantly for me at the moment was to figure out how to the get Azure DevOps pipeline to build the solution with multiple Classic WebRole projects in it. That was failing for the SAME reason.
I am having trouble getting migrations to run to create / update my Sql Db hosted on Azure. They run fine locally to my LocalDb but seem to be completely ignored when releasing to Azure.
Details:
- Asp.Net MVC 5.2.3
- Entity Framework 6.1.3
- Visual Studio Team Services (online)
- Azure Web App & Azure SQL Db (under Imagine / Dreamspark subscription)
I created a different application that didn't use CI, but used the Publish feature within Visual Studio and it published fine and worked. I have since removed that web app & db from Azure since the subscription only allows one db.
I'm thinking it may be something I'm missing in setting up the build definition in VSTS, I'm just not sure what.
I have tried:
https://blogs.msdn.microsoft.com/webdev/2014/04/08/ef-code-first-migrations-deployment-to-an-azure-cloud-service/ (this did nothing for me)
https://www.benday.com/2016/11/07/using-tfs-build-to-deploy-entity-framework-database-migrations-with-migrate-exe/ (I received a build error that I didn't have a release definition in my bin folder)
... as well as a bunch of others (I don't have the windows open any longer or I'd link them too).
My current build steps include:
NuGet restore - NuGet Installer
Build solution - Visual Studio Build
Test Assemblies - Visual Studio Test
Publish symbols path - Index Sources & Publish Symbols
Publish Artifact - Publish Build Artifacts
In my local env, EF works when I Enable-Migrations, Add-Migration, Update-Database. I'm guessing none of the above steps do this so I need one or more steps. Ben Day's blog seems like it should work, but for some reason, it's not finding my bin/release file.
The actual application deploys to Azure just fine upon release of the above successful build definition. It's just that the database is completely ignored. Using SSMS, I check the Azure db, and while it exists, it has none of my tables or data.
What am I missing?
Thanks.
**Edit - found the simple item I was missing. I need to add the connection string for the db to the web app in Azure. It now has my initial tables, and stores data using those tables, but doesn't pick up migrations. So something I've done in the last two days got my initial tables out there. Now.. to remember what it was.
**2nd Edit - So, I think the tables made it into the release db before I fixed my connection string in VSTS. One of the things I tried was creating a separate database project. I think when I pushed that at some point, the tables in existence at that time also pushed to release, I just couldn't see them because I hadn't connected the application and db together? At any rate, EF migrations are still not being recognized. I tried Ben Day's suggestion again, but I"m getting the build error:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
I am using EF 6.1.3
I ran into this as well. I was using Visual Studio to publish my Azure app service. After doing some research (https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application#deploy-to-azure), I came to learn that VS Publish transforms your web config when you check the box for "Update Database" in Publish setting, adding a connection string that refers to the database containing your _migrations table, as well as a "contexts" element under "entityFramework". You can see what a previous publish has done with your web.config by looking at "..obj\Release\InsertEFCodeFirstDeploy\transformed\web.config".
So to recreate this same action when using a build and release definition in VSTS, I added 2 XDT "insert" transforms in Web.Release.config in my service project. Mine looks like this:
<?xml version="1.0"?>
<!-- For more information on using Web.config transformation visit http://go.microsoft.com/fwlink/?LinkId=301874 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="MS_TableConnectionString_DatabasePublish" connectionString="Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=AzureStorageEmulatorDb45;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=True"
providerName="System.Data.SqlClient" xdt:Transform="Insert" />
</connectionStrings>
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>
<entityFramework>
<contexts xdt:Transform="Insert">
<context type="helpmeshopService.Models.helpmeshopContext, helpmeshopService">
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[helpmeshopService.Models.helpmeshopContext, helpmeshopService], [helpmeshopService.Migrations.Configuration, helpmeshopService]], EntityFramework, PublicKeyToken=b77a5c561934e089">
<parameters>
<parameter value="MS_TableConnectionString_DatabasePublish" />
</parameters>
</databaseInitializer>
</context>
</contexts>
</entityFramework>
</configuration>
Next, you will need to go to your App Service "Application Settings" in the Azure portal and add a connection string with name, "MS_TableConnectionString_DatabasePublish", and set its value to the same value as for "MS_TableConnectionString" that should already exist in your settings.
I have an MVC 5 web application that I'd prefer to save time with startup by pre-compiling on publication. However, when I choose "Precompile during publishing", I get the following Error:
Error 5082 Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246'
or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
error ASPRUNTIME 0 0 USIS
The Web.Config Does have a binding redirect for this Reference
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780CCD10D57B246" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
This builds and deploys fine if I do not have this precompile option checked, and the Web is working fine without issues. I just cannot publish with this precompile option checked.
I'd really like to have the website compile all views and etc only on publish, and never recompile in the live production site. Some Documentation I was looking at was suggesting this was the propose of these features... but I'm having no luck.
EDIT: I have had some success. I realized that I was purposely not deploying the Web.Config file such that a developer doesn't accidently harm the production environment configuration, but it appears that the precompile build was copying files to a temporary location, and without the Web.Config file being deployed, no Web.Config file was there, meaning no Dependency translations.
So, Now it looks like I'm going to have to deploy the Web.Config if I want to pre-compile (I had set its Build Action from "Content" to "None", and now I've set it back again.) This means I'm going to need to look into Web.Config Transformations, or etc.
Thanks,
Greg
The only thing precompilation does is compile the views. The fact that this happens only when precompilation is set means that there's something in one of your views that is generating this error. That's kind of irrelevant, though.
The best way I've found to correct this particular error is to uninstall and reinstall the offending Nuget package.
Just go into the Package Manager Console, make sure the project that generates the error is selected for "Default Project", and then run:
> Uninstall-Package DotNetOpenAuth.Core -Force
> Install-Package DotNetOpenAuth.Core
That should resolve the issue and allow your site to publish and run fine, with or without precompilation.
Solution:
It turns out that since I wasn't publishing the Web.config file, that the binding redirects were not being made. The solution was to change this file back to being published (Build Action from "None" to "Content"), and then the pre-compilation was succeeding.
For others with an MVC or ASP.NET web site that runs slow each time hitting a new page/view, I'd recommend giving this pre-compilation feature with publishing a try. It's just hidden under file options in the publication settings (VS 2012.) I chose to Precompile, and to make the site not-updatable to avoid the dynamic view/page compilations. See for more information: What effect does the new precompile during publishing option have on MVC4 applications? .
Also, to push the correct settings and connection strings to Live and Test I started using the Translation Templates "Web.Release.config" and "Web.Debug.config". These will swap out Web.config lines when deploying only. See http://go.microsoft.com/fwlink/?LinkId=125889 for more information.
I have added slow Cheetah to 2 Solutions that I'm working with. The first one transforms when I'm working with it but not on the build server. The second one doesn't transform when I build it or on the build server.
Overall I'm a little confused when it comes to how to get slow cheetah working. I've read several links from Sayed and am struggling with which one I should be following. I have added version 2.5.5 to both projects.
http://sedodream.com/2012/12/24/SlowCheetahBuildServerSupportUpdated.aspx - This one says that I need to build a packagerestore.proj file first to restore the nuget package. However I get pathing errors when I try this ... I get this error - error MSB4019: The imported project "E:\jenkins\CAREweb.net (DEV APP BUILD)\workspace\development\systems\CARE\apps.nuget\nuget.targets" was not found.
http://sedodream.com/2011/12/12/SlowCheetahXMLTransformsFromACIServer.aspx - This is the one I would like to follow because I can just put the files on the ci server in the localappdata folder for the user that the jenkins service is running under. Solve it once for everyone on the team and for every build but it just doesn't transform and I don't seem to get any kind of error. Not sure if it makes a difference but we are building on the E: drive and the localappdata folder is on the c: drive.
I've read a number of his other posts on Slow Cheetah and I've looked at a bunch of the answers from stackoverflow but haven't found one that solves my problem yet.
We are using visual studio 2010. Building the project file on Jenkins from the command line. I'm sure that if I can get the one solution working then I should be able to get the other one working but I'm just not making any progress at the moment.
Update
Also these are the related slow cheetah sections from my project file.
<PropertyGroup Label="SlowCheetah">
<SlowCheetah_EnableImportFromNuGet Condition=" '$(SC_EnableImportFromNuGet)'=='' ">true</SlowCheetah_EnableImportFromNuGet>
<SlowCheetah_NuGetImportPath Condition=" '$(SlowCheetah_NuGetImportPath)'=='' ">$([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)\..\packages\SlowCheetah.2.5.5\tools\SlowCheetah.Transforms.targets )) </SlowCheetah_NuGetImportPath>
<SlowCheetahTargets Condition=" '$(SlowCheetah_EnableImportFromNuGet)'=='true' and Exists('$(SlowCheetah_NuGetImportPath)') ">$(SlowCheetah_NuGetImportPath)</SlowCheetahTargets>
</PropertyGroup>
<Import Project="$(SlowCheetahTargets)" Condition="Exists('$(SlowCheetahTargets)')" Label="SlowCheetah" />
Try it with version 2.5.10. Ive modified SlowCheetah to add the .targets file to the project. No extra config required now. More info at https://github.com/sayedihashimi/slow-cheetah/issues/113.
I have been assigned a project with a lot of poorly written code that is based around SharePoint.
It consists of about 15 subprojects, some of them being windows services, some web services, some web applications running inside of SharePoint, some being webparts and even console applications. They all run on the same server and call each other.
There are already many issues in production but they are hard to trace down.
The original developer must have been a fan of either Salinger or Pokémon series judging by his tireless effort to catch all exceptions. Unfortunately, none of them get reported or logged, ever.
My current task is to introduce logging into the whole project so I could find now-invisible exceptions, follow tangled recurring calls and have some stack traces at least. I decided to go with NLog, seeing it's active and cool, as opposed to log4net which is perfectly fine but somewhat not as fancy to my taste.
Because the components are tightly coupled, I want to centralize logging in one file so related errors don't get scattered across the hard drive. Therefore, I am looking to have two or three different log files with five or more projects writing to each of them more or less simultaneously.
What is the best way to configure NLog to centralize logging? Should I have a config file for each project, or should related projects share them? Where should I put config file to log from SharePoint webparts? Am I going to face any permission issues?
I'm using SharePoint 2007.
The easiest way to centralize is probably to simply log to a database, one benefit being that multiple applications and write to the database easier than to the same log file. For each application, configure NLog to log to the Database target, using the same Database target configuration parameters for each. Your NLog.config file might look something like this:
<?xml version="1.0" encoding="utf-8" ?>
<!--
This file needs to be put in the application directory. Make sure to set
'Copy to Output Directory' option in Visual Studio.
-->
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
internalLogLevel="Debug"
internalLogFile="nlog_log.log">
<targets async="true">
<target name="sqlexpress" xsi:type="Database">
<connectionString>
Data Source=.\SQLEXPRESS;Initial Catalog=LoggingDB;Integrated Security=True;
</connectionString>
<commandText>
insert into LogTable(DateTime,Logger,LogLevel,Message,ProcessId,ManagedThreadId) values (#DateTime,#Logger,#LogLevel,#Message,#ProcessId,#ManagedThreadId);
</commandText>
<parameter name="#DateTime" layout="${date:format=yyyy\-MM\-dd HH\:mm\:ss.fff}"/>
<parameter name="#Logger" layout="${logger}"/>
<parameter name="#LogLevel" layout="${level}"/>
<parameter name="#Message" layout="${message}"/>
</target>
</target>
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="sqlexpress" />
</rules>
</nlog>
You could certainly log to files in addition to (or instead of) logging to a database.
I am not familiar with doing this from SharePoint, so I can't comment on any configuration or permission issues that you might run into there.
Here is a link I found where there is a discussion of getting NLog to work in a SharePoint environment:
http://nlog-forum.1685105.n2.nabble.com/Is-anyone-using-NLog-with-SharePoint-td2171451.html
That link appears to put you at the top of the NLog forum instead of the specific post. Search for this text in the forum "Is anyone using NLog with SharePoint" and you should find the right post.
Good luck!
You could also just leverage the existing logging infrastructure in SharePoint and write to the ULS logs. This way your log information can be viewed in a complete context using the ULS log viewer. For SharePoint 2007 see this blog how to write to the ULS log:
SharePoint Trace Logs and the Unified Logging Service (ULS)
With SharePoint 2010 it has become even easier with improvements to the SPDiagnosticsService class where you can use the new WriteTrace method.
Personally I log Exceptions to the Event Logger. And I use NLog for logging details, debug information or tracing.
Since NLog can be easily switched on and off I only activate it when I'm debugging or when I need to inspect an exception in production. I never was a big fan of the default tracing functionality in .NET.
I prefer simple plain text log files. Although logging to a database works great if you don't have too many "log lines" implemented in your code.
I feel like we are working on the same project! Multiple projects consisting of web projects, core dll projects, console apps, services, etc. Unfortunately I'm not working in sharepoint like you are, but I can describe how I am trying to centralize our logging.
We have 1 core .Net framework project.This is where I placed our wrapper class of the log. This project also holds the nlog dlls and the nlog config file. In this core project file you can add this which automatically moves the config when you build projects with a dependency on this core project.
<None Include="Logging\NLog.config">
<link>NLog.config</link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
We found that some web projects that don't compile a dll don't automatically pull in the config file, so we will leave that up to the build process. This helps centralize our logging so you only have to manage a single config across them all.
In addition remember when you create a logger per class, the log name should have the namespace in it, so you can make specific targets that filter based off namespace if you want different settings for particular projects.
As for centralizing where the logs end up, we chose to use a file target and specify the full path. This is because on our servers the applications run off a C:\ but we have larger D:\ which can store the logs. In our production servers, we also have multiple servers, so we are using splunk to aggregate all of our logs.
If splunk is out of the question and you are on a distributed system, a database sounds like a good idea as suggested above. If you don't want to stand up an sql instance, there are target wrappers for mongo db as well.
Hopefully helpful, I'm curious if anyone has suggestions or opinions on how I'm doing it as well!