I am updating a build script from premake4 to an older version of premake5 with no "workspace" concept, but still the "solution" one.
When I run premake, I have custom options to build two vs2015 solutions A and B:
premake5.exe --A --B vs2015
I would like the project in B to have a reference on a project in A (ProjectReference).
But it seems to do not find any project A and I am wondering if it because the project A is only searched inside the solution B, and not also A.
With premake4, we also had the function "vc2010.projectReferences" which called
"premake.getdependencies" with premake.findproject inside.
But with premake5, the "findproject" seems to be called on the scope of the current solution/workspace (premake.solution(/workspace).findproject(cfg.solution, depproj))
Does that mean that I can't link my project B with a project A if there are not in the same solution ?
Do I have to use the "external" api ?
Premake's links() function only works with projects in the same solution. But you can use externalproject() to link against a project that is not part of the solution.
externalproject "MyExternalProject"
location "build/MyExternalProject"
uuid "57940020-8E99-AEB6-271F-61E0F7F6B73B"
kind "StaticLib"
language "C++"
Related
I created a new .NET 6 Blazor Server-side project and made a couple of changes. I have a couple of files using CSS isolation (like Contact.razor + Contact.razor.css).. In the _Layout.cshtml page the template added the following:
<link href="CustomerPortal.styles.css" rel="stylesheet" />
Where CustomerPortal is my Project Name. I can see the file is generated correctly under "CustomerPortal\CustomerPortal\obj\Debug\net6.0\scopedcss\projectbundle\CustomerPortal.bundle.scp.css" and "C:\Data\Git\WebApps\CustomerPortal\CustomerPortal\obj\Debug\net6.0\scopedcss\bundle\CustomerPortal.styles.css"
BUT when I run the project, both with Kernel or IIS Express, I get a 404 not found for the CSS, if I try to manually navigate to the CSS I also can't find it. Any ideas? My csproj doesn't have any flags that would affect it.
Edit:
There is a new extension as part of the minimal setup in .NET 7, and backported to newer versions of .NET 6 as well.
Both in .NET 7 and .NET 6 you can now do:
builder.WebHost.UseStaticWebAssets();
Old answer:
You've got a couple options here to resolve this depending on the approach you want to take. I think we've figured out why it's happening, but UseStaticWebAssets() seems to not be supported for the new minimal startup code. So, here's your options I can think of off the top of my head.
Migrate your code back to the "old" way of doing application startup. This is still a supported and completely valid approach as there's edge cases that aren't supported (like this one).
Pass a new WebApplicationOptions to the CreateBuilder() method and, depending on environment, look for the static files in a separate (and correct) location. See some examples here.
With the existing builder, check the environment and use the StaticWebAssetsLoader to load static web assets.
A complete example of #3
if (builder.Environment.IsEnvironment("Local"))
{
StaticWebAssetsLoader.UseStaticWebAssets(builder.Environment, builder.Configuration);
}
That being said - I'd imagine they'll plug this hole eventually and provide parity for UseStaticWebAssets(). You can see the progress of this effort in this open GitHub issue.
For anyone else...
I had the exact same issue with a .net 6 blazor server app. For me it came down to the fact that I had changed the project name but the reference to {project}.styles.css in _Layout.cshtml was still pointing to the old project name.
Simply updating {project} here to the correct project name fixed my issue.
When I encountered this error, it was because I'd named my MVC project with a hyphen: htmx-spike.
When I generated the project from a template (dotnet new mvc -o htmx-spike), the tooling renamed the namespace to htmx_spike—with an underscore instead of a hyphen, because hyphens aren't allowed in C# identifiers—and used that modified name as the CSS filename in _Layout.cshtml.
However, it turns out that in this case the CSS location actually still corresponds with the project name, with the hyphen. So the auto-generated code is incorrect, and was causing the 404 to be returned:
Once I renamed the file in the link element to the correct name with the hyphen, everything was fine.
I had the same issue with a component I imported from another project. I solved it by closing all instances of Visual Studio, deleting the hidden folder [.vs] from the project folder, and then restarting the project in Visual Studio. On restart, Visual Studio recreated that folder and imported CSS file(s) were included.
Let's say that I have two F# projects targeting NET5 and producing console applications. Let's call them MyService and MyAdminConsole. When I build the solution, then the folders, e.g. ...\MyService\bin\x64\Debug\net5.0 and ...\MyAdminConsole\bin\x64\Debug\net5.0 will contain:
...
appsettings.json
...
MyService.exe
MyService.dll
MyService.deps.json
MyService.runtimeconfig.json
MyService.runtimeconfig.dev.json
...
and
...
MyAdminConsole.exe
MyAdminConsole.dll
MyAdminConsole.deps.json
MyAdminConsole.runtimeconfig.json
MyAdminConsole.runtimeconfig.dev.json
...
where appsettings.json, obviously, exists only in MyService because it is the service, which needs the settings.
Now, I want to build both the service and the admin console into the same folder so that admin console could have access to the same appsettings.json and I stress the same appsettings.json, not a copy of it.
This seems straightforward, right? Just add a reference to MyAdminConsole into MyService project. However, when I rebuild the solution, then MyAdminConsole.exe and MyAdminConsole.dll are copied into ...\MyService\bin\x64\Debug\net5.0 but MyAdminConsole.*.json are not. Subsequently, MyAdminConsole won't work from that folder.
Sure, I can add post build steps and actually copy these json files where needed. However, that seems ugly and just plain wrong.
I wonder what is a proper solution? Thanks.
PS This is probably applicable to C# solutions as well but I have not checked that yet.
If I understand your issue correctly then please take a look at the workarounds proposed in https://github.com/dotnet/sdk/issues/1675
Apologies if this sounds like a silly question. I'm not very experienced with how things are linked/bundled/assembled under the hood.
Before I begin, I'd like to say that I've tried reading documentation (such as https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing) to find the answer, but was unable to.
If I have a Xamarin.Forms solution and I reference a .Net Standard project:
Question 1: Does all the code from this project get compiled and included into the app such that it may be disassembled later, or is it only code from classes that I actually make use of that gets included?
Bit more elaboration:
For example, I may have a School class that expects an IStudent (inject via DI), and a Student class that implements IStudent. Both of these exist in the .Net Standard project that I reference in the Xamarin.Forms project. However, if I only actually make use of the Student class (by registering it with type IStudent in my IoC container), will the code from School get included in the built app as well?
Question 2: If all the code from the project does get included, is there a way to forcefully specify which classes to include/exclude by way of some configuration setting, attributes, 3rd-party library, or something else?
As far as i know everything in the NETStandard project get compiled and shipped with the app.
If you want to remove unused code from compiled assemblies you have to use the linker.
To link everything, you have to select "Sdk and User Assemblies".
The linker tries to dont strip away mthods and fields you are using, but often is too aggressive (for example, methods referenced only by reflection will be stripped).
Luckily there are few methods where you can fine-tune the linker behaviour and make it work. Some link to elaborate on:
Linker in iOS and Android
https://learn.microsoft.com/en-us/xamarin/ios/deploy-test/linker
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/linker
Official doc about the linker config:
https://learn.microsoft.com/en-us/xamarin/cross-platform/deploy-test/linker
Useful blogposts:
https://xamarinhelp.com/xamarin-linker/
https://medium.com/#harrycblum/reduce-your-xamarin-app-size-with-linking-26247edc87f6
When trying to open an older solution in VS2017 there is an old Unit Test project that is giving me a problem when building.
I keep getting the following error when building this test project:
Could not load file or assembly 'file:///C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. The system cannot find the file specified.
I checked the project's references and it appears to be referencing Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Additionally there are no code errors. How could I ever figure out if it is one of its dependencies that it can't find?
I had a similar issue (with the additional message The "BuildShadowTask" task failed unexpectedly) with a project originally developed with VS2010, and got to spend the last few hours learning about yet another legacy facet of the build process.
There is a good chance that you are dealing with private accessor files (.accessor), which were deprecated in VS2012 (original source). This was foreshadowed in an announcement from the VS2010 team that they were no longer working on these features.
There is also a chance you're just dealing with erroneous refs to the wrong version of UnitTestFramework, but a NuGet restore should fix this. If not, see this GitHub thread for a possible fix (manually change the ref to the public folder), or move to the new MSTest.TestAdapter and MSTest.TestFramework packages (see MSDN support thread).
Solutions
A. Edit the unit test .csproj and change the item Include references from Shadow => None:
<Shadow Include="Test References\namespace.accessor" /> to
<None Include="Test References\namespace.accessor" />
B. Better yet, simply delete all the .accessor files from the unit test project's Test References folder.
Ideally, you would also rewrite your unit tests to remove references to private methods, either by re-architecting to separate concerns or by changing properties to internal and using "friend" with the InternalsVisibleToAttribute.
For those who need to continue supporting testing of private methods for some reason, the same post provides the following suggestions to the logical question "What is available for me then?":
For those who wish to continue testing internal APIs, you have three options:
Use the Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject class to assist in accessing internal and private APIs in your code. This is found in the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly.
Create a reflection framework that would be able to reflect off your code to access internal or private APIs.
If the code you are trying to access is internal, you may be able to access your APIs using the InternalsVisibleToAttribute so your test code can have access to the internal APIs.
However, there is not any good replacement for Code Generation for the new features added by the lanugage teams. You may create the TestMethod stubs and then remove the internal code. You only need to keep the stub itself.
Further reading / sources that helped me piece this together:
VS 2005 ASP.NET explanation of accessors
2008 blog article explaining how to work around this for build servers
MSDN forum thread with discussion on accessor purposes, implementations, and workarounds. Start about 1/3 down.
MSDN BaseShadow docs
MSDN PrivateObject class
Right click the project references folder. Add reference > Assemblies > extensions. Check Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1, and uncheck any older version.
This is related to Visual studio Enterprise 2015, add new load test was failing: and spiting as "Unable to find assembly 'Microsoft.VisualStudio.QualityTools.LoadTest, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Due to Assembly installed in public assemblies shows as version 10.0.0.0 which is missed in GAC,
GAC had only 10.1.0.0. Once GAC updated with 10.0.0.0 and restart VS 2015. should resolve the issue similar to this.
Some more detail for better reasoning, System Assembly path and project path
DLL path
......\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
.CSProj reference version
I had a same issue while I was upgrading project to .Net4.8 in Visual studio 2022 earlier we were using Visual studio 2017.
Error:
The "BuildShadowTask" task could not be loaded from the assembly ***\Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll. Could not load file or assembly 'file:///***Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll' or one of its dependencies.
Solution : I removed ".accessor" files from project as that is being used for accessing private methods(most probably accessor is depricated). Then we used "PrivateObject" class for accessing private members in UnitTest.
Later we updated Unit Test case. Code references could be found from below articles.
Unit test private methods?
Unit Testing: Exposing Private Members
I had a similar issue (compile project in server Jenkins)
Solution:
Include VS.QualityTools.UnitTestFramework to reference project, whit Pakage Manager:
PM>NuGet\Install-Package VS.QualityTools.UnitTestFramework -Version 15.0.27323.2
https://www.nuget.org/packages/VS.QualityTools.UnitTestFramework
Try to fully uninstall Visual Studio 2017 (not repair). Then download the latest version and install it. Remember to check if MSBuild is added to installation files. Remember to delete folder inside Documents: Documents\Visual Studio 2017. In my case, this simple solution fixed all errors.
I am newbie in .net.Today I have created a sample. In that sample, I have stored data in database using N Tier architecture. If I want to use to Use BL or DAL method in other project(I mean BL method in UI or DAL method in BL), I found two ways.
First one is - Right click on project << Add Reference << Select Project in Project tab
Second one is - Right click on project << Add Reference << Select DLL in Browse tab
Could anyone tell me that is there any difference between both of them as both works same.Is DLL way better then Project Reference.If yes, then what is the benefits?
Thanks in advance.
Regards,
Mohit Kumar.
The correct way to do it is to add a project reference.
one of the most important differences is that a project reference is updated automatically when you change the referenced project.
for example- If you change your DAL method from GetEmployees() to GetAllEmployees() then you can use GetAllEmployees() immediately in your BL class, without compiling your DAL first.
You typically use the project reference when the reference is part of your solution. In this way the relevant latest code is always used.
You will reference an assembly when it is a third party component or not part of your solution. This is somewhat more static as you will be using the code at the version represented by the assembly. So any changes to the assembly will require you to physically overwrite the referenced assembly with the updated dll.
HTH
The differences between the 2 have already been answered, however just to add to that, I think the only difference between the 2 in VS is that if you add project reference it still adds a normal dll reference, except the reference is to the Debug location of the projects binaries (i.e. bin\debug\project.dll), so in essence you could probably just Add Reference in the same way and point straight to the latest compiled dll.
I have came across a very interesting difference between the two approaches, but in the context of having 2 projects, one shared among multiple developers and one private to each developer.
Let us say that the shared VS project is called projectS, and the private project is called projectP
Now if the objective is to have a centralized development, and the developer needs to access source definitions from both projectP and projectS so that pressing "F12" or "Go To Definition" in VS would bring complete definition, then we have to use the Project Reference and not the DLL reference, otherwise pressing F12 would bring the definition from the compiled "metadata" excluding all developer comments and other relevant data.
When adding a Project Reference to projectS from within projectP, VS will resolve references to the files included in projectS and referred to from projectP using the source definition in projectS, and not from "metadata" of the DLL associated with the referenced project (ProjectS.dll). Still, the projectS.dll will be included in the References folder and Development time, Execution time will be OK.
When adding a DLL reference, VS will resolve references from "metadata" stored in ProjectS.dll, even if the Referenced Project was added to the Solution of projectP as an "Existing Project". This would allow Execution time to be OK, however, Developer will not be able to press F12 and go to Source definition in projectS, he/she will have to do this manually from the solution search area.