I need to obfuscate a dll that is used in a ASP.NET project, the deployment project pruduces a setup.exe which I want to distribute. I have the VS 2008 Dotfuscator installed but when I build the deployment project the project that creates the dll is rebuilt before it is added to the deployment project and added to the setup.exe. Any suggestions on how I can get round this?
Many thanks
Lee
Just set the dependencies using project references.
Related
I was developing an ASP.Net Core Web Api together with dlls specyfic to the domain. I have also developed a dll which turned out to be the one that can be shared across organization as NuGet dll. I created that dll in the same solution where i have my AspNet Core app. In consequence each time I run a build, version of this Nuget is bumbed up even if no changes were made to that dll.
I have 2 questions:
Should I move this Nuget dll to separate repository? Is this a best practice?
Can i somehow configure a task in AzureDevops pipeline in a way that version should be bumped only when there is a change made to that dll?
Should I move this Nuget dll to separate repository? Is this a best practice?
It depends on your actual application. If the project of this NuGet dll in the solution is independent and not related to other projects. The best practice is to move this Nuget dll to separate repository.
This helps to manage the shared nuget dll.
Can i somehow configure a task in AzureDevops pipeline in a way that version should be bumped only when there is a change made to that
dll?
AFAIK, there is no such task to achieve this. But we could try to modify current pipeline to only build AspNet Core app project instead of the solution, and create a new pipeline only build the nuget dll project and give the path filter:
In this case, each time run a build, version of this Nuget is bumbed up only changes were made to that nuget dll project.
I am currently working on automating the build and deploy of an asp.net web application which is developed using vb.net in visual studio. Currently, developers are building the solution and projects using visual studio IDE. In the solution, they have deployment/setup projects (vdproj) for each environment (e.g.: app.setup.dev, app.setup.uat, app.setup.prof) which creates msi for the deployment and the web.config is embedded on it.
We are using github for scm, jenkinsfor build/CI and udeploy for deployment.
I am able to build the solution using msbuild cli thru jenkins. However, vdproj cannot be built using msbuild. Alternatively, I installed Visual Studio and MS VS Installer Projects Extensions in my build server, then build the vdproj using devenv. I am not sure if that is a correct way, maybe it is just a workaround.
What is the appropriate way to package the deployment artifacts (contents files, dlls, web.config) and deploy them? And How? If there’s another way to do it rather than creating MSI, it would be great as I don’t have to get a license for the Visual Studio in my build server.
I am currently working on automating the build and deploy of an
asp.net web application which is developed using vb.net in visual
studio.
Maybe you can try publish asp.net web-app by msbuild command-line.
1.As far as I know, we can build and deploy by Visual Studio, see this document.
2.And without VS, you can build and deploy(publish?) by msbuild command-line, there are many resources about this topic.
See:
How to deploy an ASP.NET MVC application on build using MSBuild in Visual Studio 2015?.
How to build and deploy a web deployment package using MSBuild
Using MSBuild.exe to “Publish” a ASP.NET MVC 4 project with the cmd line
In this way, you can get similar function by specifying the parameters and don't need to have VS installed in the server.
What is the appropriate way to package the deployment artifacts
(contents files, dlls, web.config) and deploy them?
Do you have to package them into .msi or .zip and then publish it. If not, simple msbuild command like: msbuild xxx.sln /p:WebPublishMethod=xxx /p:PublishProfile=xxx is enough.
Not certainly sure if it's what you want, hope it helps.
I created a simple Web API project in Visual Studio 2015 using the .NET Core Framework. When I publish this project using the default settings, it creates the following:
In total there are 155 DLLs, 77 in the PublishOutput root and 78 in the refs folder.
Why put all the DLLs in the publish folder? Couldn't it just
reference the DLLs where they were installed from a single shared
location ?
Dotnet core tend to be very minimal as opposed to the previous versions of .net framework.
In dotnet core, the main purpose was making the core framework as small as possible and if you need more stuff, bring it in through NuGet packages.
So, many dependencies that used to be available in the framework are now moved to the NuGet packages and as you know there is a chain of dependencies in NuGet packages, so we will end up with so many libraries in our publish output, which is fine.
Another point being, most of the time, we're using project templates with too many dependencies that might not be needed whatsoever. So we can either start with a very minimal template and add needed stuff in it, or remove useless stuff from a more chuncky template.
I had a similar issue. When my local computer was upgraded from Net Core 2.0 to 2.1, my Core We Application which references a NetStandard application started publishing all DLL's in all referenced projects. I migrated my Core 2.0 application to 2.1 to match the highest version of SDK installed on my local and I could see my issue is now resolved. Publishing from the migrated(upgraded) application produced only the required DLL's. Hope this helps.
I am using Visual Studio Express 2013 for Web & developing web APPS ( not sites ) on .net 4.5.
I build,test & view my site on a local IIS 7.5.
I host on Azure - using App Services.
I build and release to an App Services slot using VSTS Online
I have my classes in an App_Code folder - files are marked as compile
This appears to be the only way I can set this up to work on local IIS ( or am I missing something ?)
And it all works - all classes are available
But I need to build and release on VSTS/TFS ( using VS Team explorer to push)
I am using the standard Azure Web App build definition module on TFS -
Which takes the App_Code folder and moves it into the bin folder - but does not compile it - thus breaking the classes when they are deployed
I have tried renaming App_Code but that breaks local and still does not compile on TFS
What am I missing - how do I get TFS to either compile my classes OR copy the App_Code folder to the root ( not ideal but hey it works )?
In TFS, dll files will be generated under bin folder when you build a Class Library project. This is the correct phenomenon. Suggest you to create a Nuget Packages to manage your class libraries . And you can add a "NuGet Installer" task at the top of your build definition to restore the nuget packages for your solution.
If you are using vNext Build on TFS. There also has been a very detail tutorial Build and Deploy Azure Web Apps using Team Foundation Server/Services vNext Builds for you reference.
I want to use an ASP.NET web application which was built using visual studio 2008 to 2013. will keep the .net framework to 3.5.
My concern is: There will be changes to .csproj and .sln after opening the project in 2013 but what about the dll to be deployed. would i need to update the hosting environment to 4.0 or any dependency upgrade?
The csproj and sln files will indeed be upgraded, but that has no bearing on the output of compilation.
As long as you continue to build for .NET 3.5, there shouldn't be any additional requirements to deploy your application. One thing to keep in mind is that VS2008 web deploy projects and database projects have been deprecated, and no upgrade path for those exists. So be careful if you're using either of those.
The safest approach for you will be to test the upgrade. Install VS2013, which runs side-by-side with VS2008. Open up the old solution, let VS update it, then do a test deployment. If there's a problem, just revert the change to whatever your last source controlled version is.