I created a new .NET 6 worker service project with dotnet new worker -n MyProject. I then created a new solution with dotnet sln new -n MySolution. Finally I added the project to the solution with dotnet sln add .\MyProject\MyProject.csproj. When I opened the solution in Visual Studio 2022, I was greeted with a bunch of "errors" in the default Worker.cs file:
The project will build and run just fine. The problem appears to be with the new Implicit Usings feature of .NET 6. Visual Studio is not recognizing that the red-underlined items are implicitly imported from their namespaces, and don't have to be referenced manually. There is an additional error in the error list:
Project "C:\LongDirectoryPathHere\MyProject\obj\MyProject.csproj.nuget.g.targets" was not imported by "C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.targets" at (35,3), due to the file not existing.
I checked and the file does indeed exist.
Apart from being quicker to use, the reason I use dotnet new instead of creating the solution/project in Visual Studio is that Visual Studio complains about long paths and refuses to create projects that would output files with a path length over 259 characters, despite Windows 10 supporting paths that are thousands of characters long. The full path to the "missing" file is exactly 261 characters.
Is this caused by the max path issue, or is it something else?
Related
Can someone assist with the following error which i am getting while building SSIS project using msbuild. I am having Visual studio 2015 in the machine. Using MSBuild 14.0
"*
error MSB4041: Th e default XML namespace of the project must be the
MSBuild XML namespace. If the project is authored in the MSBuild 200 3
format, please add
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the
element. If the proje ct has been authored in the old 1.0 or
1.2 format, please convert it to MSBuild 2003 format.
*"
I have gone through some articles online but couldn't find solution with this scenario.
*" I have gone through some articles online but couldn't find solution with this scenario.
I'm afraid the answer is negative. For now this scenario(build SSIS project using msbuild) is not supported.
Someone has post this issue in DC forum, see Support SSIS, SSRS, SSAS in MSBuild. So if you're trying to use azure devops for CI/CD process, please vote and track this issue to get notifications when there's any update. And if you're using other tools for CI/CD process, I suggest you open a new feature request to support SSIS building for stand-alone msbuild tools in local machine.
And here're two workarounds which may help:
1.Since you have VS2015 installed, instead of msbuild command, you can try using devenv command.
For VS2015, we can find devenv.exe and devenv.com in path C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE. Both devenv.exe and devenv.com works for this, but note: Using devenv.exe directly prevents output from appearing on the console.
So devenv.xxx ... xxx.dtproj /build can work to build the SSIS project.
2.We can find binary(Microsoft.SqlServer.IntegrationServices.Build.dll) of the SQL Server Data Tools in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. Then we can use msbuild UsingTask element to call the tasks defined in that assembly.
The core is to call DeploymentFileCompilerTask task for SSIS build in our custom msbuild target after defining this statement:
<UsingTask TaskName="DeploymentFileCompilerTask" AssemblyFile="C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.SqlServer.IntegrationServices.Build.dll" />
More details please refer to here and here.
Update:
If we have several Database projects and SSIS projects in same solution. Using command like devenv.com xx.dtproj directly will actually build all projects.
So I suggest we use command in this way:
Open Developer command prompt for VS
cd to solution directory
use command: devenv.com SolutionName.sln /Build Development /Project SolutionName\xxx.dtproj /ProjectConfig Development
This will only build the SSIS project actually.
In addition: If you see the message The project 'DatabaseProjectName.sqlproj' will close once model building has paused. If it doesn't affect your build, just ignore it. After my check if won't actually build Database project(the output of database project is empty) if we use command above.
I'm trying to build my solution and package up the web app into a web deploy (.zip) package to be deployed.
I've added the Visual Studio Build step with the following MSBuild Arguments:
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
And I've set up the Copy and Publish Build Artifacts step to copy all .zip files to the drop folder.
The build completes successfully but nothing is copied to the drop folder because there are no .zip packages that get created.
So when I look on the TFS server, the only thing in the 'a' folder is an empty 'drop' folder. And in the 's' folder is the solution directory with a PrecompiledWeb folder in it. Not sure what that is but it doesn't look like the deployment package (and it's not a .zip).
Any ideas?
I have tried the same on VS2015 MVC web application using VSTS and TFS 2015.2.1 both. I had to do a slight change to the Build arguments in Visual Studio build. That is removing the trailing "\" in /p:PackageLocation="$(build.artifactstagingdirectory)\".
Here is the argument I passed to Visual studio build step
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)"
Then I used Copy and Published Build Artifacts (Deprecated in VSTS you should use Copy task and Publish task instead of this task) as shown below
This gives me output as below.
First suggest you manually remote in the build agent and build the project through MSBuild command line with arguments to see if the project builds properly.
This will narrow down the issue is related to the environment on your build agent or your build definition.
You should directly use /p:PackageLocation=$(build.stagingDirectory
Besides since you have multiple assemblies that are referenced in the web app. Please also double check dependencies that are building in the correct order or referenced correctly.
Make sure the ASP.NET development workload of Visual Studio is installed.
If DeployOnBuild is having no effect, you may need to install the ASP.NET Development "workload" with the VS setup tool.
There are specific .targets files that, if they don't exist, cause these parameters to be silently ignored. Installing this adds those .targets and the parameters become active, allowing the .zip to be created.
For me (VS 2017) the relevant target file (or one of them, anyway) that was missing but is needed is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets
If it is missing, you'll need to install as above, and if it is there, then you have a different problem. ;)
I have a solution, which consists out of 2 projects: regular class library for .NET 4.5 + website (not web application) project.
When I build this solution with Visual Studio - all referenced assemblies from Nuget packages and local references are copied to bin folder of website project.
If I try to build solution with MsBuild - bin folder of website project does not receive any assemblies.
Website project is not selected to be built in VS configuration (which is reported by message in both cases)
Edit - here is additional explanation.
When I clone a project from git - bin folder of website contains only 4 assemblies already checked in:
If I will run msbuild command with /t:Build or /t:Rebuild and /p:Configuration=Release;Platform="Any CPU" - I'll receive just an output of postbuild event in my other project, included in solution:
However, if I execute build from VS (Ctrl + Shift + b) in Release/Debug config - bin have all required assemblies for running web application.
Edit 2: Link to example solution - https://github.com/akuryan/csharp-website-test
When one builds it with msbuild TestApp.sln /t:Rebuild /p:Configuration=Release;Platform="Any CPU" - this results in only Test.Core.* and LetsEncrypt.Umbraco.dll (initially checked in) found at ~\Test.Web\bin\ (where Test.Web is website project). If one builds TestApp.sln with VisualStudion 2015 (I suppose, 2013 and 2017 will be the same) - ~\Test.Web\bin\ gets whole amount of assemblies.
Different results with MsBuild and Visual Studio
That because the all dll.refresh file in bin folder alongside the binary file are ignored by .gitignore.
Since Web Site projects do not have any project file (.csproj) to put the assembly references, the *.dll.refresh files are used by MSBuild to understand the assembly references. The contents of the file is the relative path to the .dll via the packages folder for the solution. When you ignore all those .dll.refresh by .gitignore, MSBuild could not understand how to handle the dll files.
To test this, I created a website project, add a nuget package to it, then delete the dll files but keep the .dll.refresh files in the bin folder. Build the website project by MSBuild command line:
msbuild.exe TestWebsite.sln /t:Rebuild
After this command complete, the dll files are copy to the bin folder.
So build and package restore to work it looks like you need to keep the .dll.refresh files in the bin folder. You can remove the other binaries from your version control system.
Note: If you want to get those .dll.refresh back, you can use the command line in the Package Manager Console:
update-package -reinstall
Hope this helps.
When I use the option Publish... selecting as target the file system in Visual Studio 2015 it compiles the code, do the XML transformation in the Web.config files and copy the files to the folder I specified.
It does not copy any *.cs file as expected since it is compiled.
Something that I don't understand is why it publishes the Nuget Config file (packages.config), after all, the files needed are already in the bin folder.
I found this question that says how to avoid but not the reason they decided this file would be usable on the server.
Can I stop VS from publishing packages.config?
Anyone know why packages.config end up in the publish folder?
I have a Visual Studio solution that contains 16 C# projects. I also have a separate build.proj file which contains three <Target>s:
Build, which contains an <MSBuild> reference to the *.sln
Package, which contains the <MakeDir> and <CopyCommands> to copy the built DLL/EXE files along with various data files to a $(StagePath) directory.
Deploy, that copies files from the stage path to a deploy path.
I was able to run the command xbuild /t:Deploy build.proj to build the *.sln and copy its files to the appropriate location, until recently when IT decided to move my Documents folder onto a network drive.
Now, whenever I try to run this xbuild command, I get several errors like the one below. (The reference is to one of the dependencies within the same solution.)
error CS0234: The type or namespace name `Util' does not exist in the namespace `Contoso'. Are you missing an assembly reference?
But whenever I do a “Build All” on the same *.sln from Xamarin Studio, I get a successful build with 0 errors and 0 warnings. So why can't xbuild find these assembly references if Xamarin Studio can?