This question is related to How to speed up aspnet_compiler.exe?
The answer mentions using Roslyn instead and provides the link to this post - https://devblogs.microsoft.com/dotnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/
But this post does not explain anything, except instructing to reference a certain NuGet package, which simply copies roslyn binaries to _PublishedWebsites\<TheWebAppName>\bin\roslyn. Now maybe this is all it takes to switch to roslyn at runtime after that folder is deployed. I do not know. What I do know is that our build calls the AspNetCompiler task to compile the Mvc views to make sure they are OK before we deploy them. We may even precompile them to include with the deployment package to avoid runtime compilation at all.
Anyway, it is unclear and I could not find it anywhere - how do we use Roslyn instead of aspnet_compiler.exe during the build?
Related
Assuming I have packaged a .net application e.g. MyConsoleApp.nupkg and have it available in a source, how would I go about "installing" this to a folder, such that I can run it from this folder:
my-folder/MyConsoleApp.dll
my-folder/Newtonsoft.Json.dll
....Other references....
I have tried nuget install with packagesDirectory option, but this gives the familiar output in the packages folder e.g:
myconsoleapp/1.0.0/lib/netcoreapp3.1/MyConsoleApp.dll
newtonsoft.json/11.0.1/lib/netstandard2.0/Newtonsoft.Json.dll
newtonsoft.json/11.0.1/lib/netstandard1.3/Newtonsoft.Json.dll
newtonsoft.json/11.0.1/lib/net20/Newtonsoft.Json.dll
....Other references....
I imagine there is a msbuild target which copies the correct content out of the packages directory to a build directory - is there an easy way to use this?
I have tried using dotnet restore/build with variations of a .proj file using PackageReference which make no reference to a specific build target, but these have not worked:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="MyConsoleApp" Version="*" />
</ItemGroup>
<Project>
I don't want to make a MyDummy.csproj which references my console app (or asp.net core app) to achieve this because it doesn't seem very clean, and I'm worried about getting the SDK and <PropertyGroup> stuff compatibly correct.
I understand this may not fall under best practices, but I would like to see if it can be done in any case.
Background
I want to deploy a mesh of c# core libraries, applications and plugins such that they all use the exact same versions.
The libraries (core application framework) are referenced by the applications (web apis, background service workers) and by the plugins (dotnet-script with nuget references to the libraries). The plugins are in turn invoked by the libraries.
The plugins must reference the same library assemblies as loaded by the applications, yet are resolved as NuGet references at runtime, which avoids a long list of guessed references to System.Etc.Dll in the scripts and related runtime failures.
Installing the applications via nuget packages leads to an interesting way to get a single source of truth for all - the nuget source.
I've seen how dotnet-script manages to do it:
https://github.com/filipw/dotnet-script/blob/master/src/Dotnet.Script.DependencyModel/ProjectSystem/csproj.template
During the msbuild of a project that has packagereferences, you are able to get access to the list of references. This is similar to doing a full build of a dummy project, but looks likely the only way to do this as of now - nobody seems to want to answer so I'll leave this here!
I've tried to add a new reference to my .NET Core project.The strange thing is that I can access also the projects that are involved in my reference. For this example, i should be able to see the Repository project from service, but should not be able to access Entity Project.However , I can still access the entities object from Service.
How comes ?
References in SDK-based projects are fully transitive so - similar to many other package managers like npm or maven - you all the transitive references are available in the project to make sure the app compiles and runs cleanly, e.g. there are no unresolved references when the dependency is referenced and all assemblies are part of the build output and ready to run. (there may even be conflict resolution applied to conflicting version of assemblies resulting in the generation of binding redirects.)
In previous versions, you would need to install NuGet packages or add additional project references to other projects as well to not get build errors or type load exceptions.
Currently there is no perfect workaround if you want your project to do all the things needed to be able to run and resolve conflicts correctly but not pass transitive references to the compiler.
If you only need a dependency to build a project, but not to run it, you can mark a package or project reference as PrivateAssets="All" (add as attribute to the reference in the .csproj file).
If you want to enforce API usage - e.g. for layered APIs, consider writing a roslyn analyzer that will emit warnings if you reference APIs from places you don't want to. this may be suitable for large projects where tooling is needed to maintain the desired architecture.
We've got an Asp.Net web application we're trying to get pseudo-deployed to a folder, and I'm starting to think Microsoft are crazy -- why is it so hard to get a WAP to do a "Local FileSystem" deploy as part of MSBuild?
I can build with this:
msbuild .\SubSite.csproj "/p:Platform=AnyCPU;Configuration=Release" /t:Package
And get a nice package.zip which I can deploy to a website...
However, I have two projects in my solution, which I need to combine before I ship them, so I want to deploy both packages into a folder, and then re-package that folder. Despite the documentation on technet to the contrary, it doesn't seem to be possible to do:
msdeploy -verb:sync -source:package=.\SubSite.zip -dest:contentPath=.\Www\SubSite
Because you get the error:
Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Does anyone have a suggestion of how I could web deploy two sites inside one another without manually copying files out of a "PackageTmp" folder? I mean, I'm aware that I could just skip zipping the package and manually copy the files out to do this, but I'm not happy about having to create a custom target, and there's no other way to find that just to do something that should be built in.
We did eventually figure out how to do this, but I'm not really happy about it ;-)
Basically, (as mentioned elsewhere on so), you can call msbuild with the target set to _WPPCopyWebApplication. You can also specify/override the WebProjectOutputDir property when you do that. Something like this (where ${name} are variables we're using)
msbuild ${SourcePath}\Www\UI\UI.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Mobile\Mobile.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\Mobile" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Service\WebService.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\WebServices" "/t:_WPPCopyWebApplication"
We can then package up the whole "AppRoot" in a separate step.
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.