I am at a new role, and am trying to get started with the Visual Studio solution I will be working on - I am having an issue with the sqlproj within the solution - which is required to get my local instance up and running!
The issue is the publish step - I get the error "Could not find the file c:\Repos<whatever>\debug\bin\Site.dacpac.
Several different sources have suggested simply doing a Rebuild of the project, but VS always skips this project - even if I try a Clean first, or Clean the entire solution and Build after.
I have checked that the build is currently set to produce Debug code, and confirmed the project is set to be built in the Debug/All CPUs configuration.
Is there a way to force it to rebuild?
The only thing that I can think of is that the instructions I'm following request the developer to install SQL Server 2017, but I'd already installed SQL Server 2019 - could there be an issue there?
Resolved: for some reason the sql project didn't want to work with SQL 2019,
so I uninstalled that, and replaced with SQL 2017, and it worked.
I had expected '19 to be backwards compatible with '17, but apparently not.
Related
I've been working on a project template today, first time doing so but it has been going alright. I'm almost finished but have now run into some weird issue I can't figure out.
For some reason which I don't know, whenever I try and debug my project template it is now stuck to using some old version of it. No matter what or how much I change then rebuild and try to debug - it still uses some weird old version stuck in some sort of limbo.
I can't seem to figure out where it's finding this file, I've cleared my temp folder. It doesn't show up as installed when I go to Manage Extensions in Visual Studio.
Any ideas what might have happened? There are no errors or warnings.
I was able to solve this by deleting all files inside %LOCALAPPDATA%\Microsoft\VisualStudio\16.0_cfa111feExp\Extensions. After doing so, I restarted VS and loaded up my project and rebuild (not build) the solution.
After that, it now shows the up-to-date version of the project template. What caused this and how to potentially prevent it in the future - I still have absolutely no idea.
I use Visual Studio 2019 Version 16.4.2
Basically this:
I created a fresh project in Visual Studio 2019 using the VSX c# template.
I moved a bunch of files from an older VSX project (for VS 17).
I compiled and ran the project - errors started emerging.
I addressed one error, ran the project - got another error.
I started addressing the second error and in the process of fixing it I noticed that now VS is for some reason compiling an unknown external project whenever I run my project. I realized it because once the program hit the error and instead of jumping into my code and showing me the line, it showed me this message: "The source file is different from when the module was built. Would you like the debugger to use it anyway?" Also whenever I changed something in my code files now - the changes never apply. Moreover, the first error (which I have already fixed) resurfaced again, and when the debugger tried showing me the place of the error - it clearly used the new file, thinking that it's an old one (even if I change the new file to have empty space in the line where the error was, the debugger will still stand on that empty line, talking about the error).
Now whenever I create a new VSX project, even an empty one, and compile/run it - the studio runs that unidentified external project (I have absolutely no clue where that project is, even the files that the debugger uses have no influence on that project.
UPDATE: I deleted Visual Studio cache folders (C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxxx) as well as reset the experimental Visual studio with the start menu prompt "Reset Visual Studio 2019 Experimental Instance". Now, when I compile my VSX projects, a clean and empty Visual Studio instance is launched - my extension code is ignored.
The Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.
I am using Roslyn for application scripting via Nuget Package Manager. Setup should be rather simple. Create new project and, in Nuget manager, add Microsoft.CodeAnalysis.Sripting package. After couple of confirmations you are ready to go.
Next step should be checking for installed packages update. Currently, there are 5 updates that are shown after initial installation. Again, it is pretty straightforward to do this.
However, immediately after the update, two of those packages show yellow triangle in Reference node of the project.
I have tried to resolve this following SO and other hints but nothing helped me so far.
At the end, I have installed new VM with Windows 10 Pro (with all updates) and VS2017 Community Edition. After that new Windows Forms project (.net 4.6.1. based for x64) was created and scripting package is added. Unfortunately, yellow triangles are still there (after update).
Problematic packages are System.ValueTuple and System.Security.Cryptography. X509Certificates.
Also, after cleaning and rebuilding the solution, a number of warnings (MSB3836) - explicit binding redirect on "System..." conflicts with autogenerated binding redirect.
Solution to this problem might shed a light on problem with more complex solution that I stumbled upon after migration to VS 2017.
So, what is the reason for such behavior? Remember, this happens on new installation of OS and VS with simplest project possible.
Visual Studio 2017 Communnity Incorrectly Updates Roslyn Scripting
I got the same result with you steps. This issue only occurred on the Visual Studio 2017 not Visual Studio 2015. That should have some issue with package Microsoft.CodeAnalysis.
To resolve this issue, I would like provide you a workaround:
Update packages "System.ValueTuple" and "System.Security.Cryptography. X509Certificates" first, then update other packages.
It works fine on my side, you can check if it works for you.
In order to track this issue, I have create a new issue on GitHub:
https://github.com/dotnet/roslyn/issues/22290
If you have additional information to add, you can add comments below that issue. And you can check the feedback from this link.
I have a TFS 2013 RC install running VS 19,12, and 13 on the build agents. I have a build definition using the CopyDirectory action from the toolbox and when I place anything other than a hard-coded path in either the source or destination box, I get this error
The build process failed validation. Details: Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.DropLocation".'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'.
I have googled this and nothing seems to come up that works.
Any ideas would be great, as we are blocked on using this.
Thanks,
Devin
I believe that you need to use the 2013 build template if you are using the 2013 Build Agent. If you don't want to, or can't, upgrade your template you should reinstall the 2012 build agent which works fine with 2013.
The new templates are on the server, rather than in VC, but you can download them from the build definition screen and check them in if you need to customize them...
So two solutions:
Upgrade your templates to 2013
Downgrade your build agent to 2012 and use the existing templates