Has anyone ever bothered about the fact that BizTalk has a lot of annoying deployment/building problems.
For example if I use c# assembly classes to be build/deployed I regularly get sgen.exe errors, which get fixed if I remove them from my assembly, however then some dependencies are giving problems again, which then means I have to rebuild it and restart visual studio because they don't trigger the assemblies otherwise. And yes I always use the build event command:
"C:\Program Files\Microsoft Visual
Studio 8\SDK\v2.0\Bin\gacutil.exe" /i
$(TargetFileName)
I also experience a lot of problems wwith serializing String or Booleans etc while building, which also become fixed after I restart my visual studio solution.
Also when you want to import an .msi file you have to unenlist & remove all running instances to have it deployed decently.
And let's not forget about restarting your host instances, which is an option on your visual studio project but barely ever works so manually restarting your host instances has become more than a routine.
Let's face it, there's a lot of other things which also keep on rising like references problems etc, and I'm sure I can think of a couple more after a day of work.
Does anyone have some tricks regarding these issues? Because I encounter them hourly. I was just wondering if other people encountered these too and maybe solved a couple of these issues.
About restarting host instances, I have found the following "bts-reset" PowerShell script to be extremely useful:
http://winterdom.com/2006/09/btsresetwithpowershell
It doesn't solve the problem, but it's faster to use than restarting host instances from the BizTalk admin console.
Otherwise, I agree with you that deployment is really too complex (especially when you have multiple projects/applications with dependencies between them), but the only "solution" I have is to carefully break down your projects/applications in a way that will minimize the problem.
We installed SP1 for BizTalk yesterday. The performance has improved a lot! Starting our orchestrations used to take ages. Only takes a couple of seconds now!
Related
I have a ASP Project running Visual Studio 2013 having very bad Performance while debuging/running the Project. The same Project running on a normal IIS Server is super fast with no Problems. Other Projects are running also super fast with no Problems (also on VS2013).
I have already tryed the following:
Delete All Breakpoints does nothing.
Debug or Release version, doesn't matter.
start without Debugging has the same problem.
Putting my project on a full IIS implementation on a web server runs it super fast with no problems.
Clean Solution, or deleting the .suo also do nothing
comment all the CodeBehind and the JavaScript
the solution with symbol loading from Visual Studio debugging/loading very slow also dont work.
Another often mentioned solution is to deactivate Intellitrace, but I don't found how to do that in VS2013 (the Intellitrace MenuItem in the Tools/Options Menu is missing)
There are many empty ScriptDocuments created while running, dont know if that has anything to do with the Problem.
Thanks for any Ideas!
This may sound strange, I had the same problem and tried all suggestions I found on the internet. The cause for me was I has a blank DVD in my drive. I found this by looking at where Visual Studio was trying to load the symbols from "my d drive (dvd)". After I ejected the blank DVD it was back to normal. This was very strange but just saying, check where VS is trying to load the symbols from in the output window. Hope this save someone from running round in circles.
I know that many people have had this problem... but I am now having it and cannot solve the issue. VS 2008 is randomly giving me an error after working on a project for weeks. When I set a debug point, I get a warning: The breakpoint will not currently be hit. No symbols have been loaded for this document.
I have re-built the solution with no debug points and re-tried. I have also tried to Load Symbols from path and that has not worked either... Can someone please help walk me through the necessary steps to getting my debug function working again.
Thanks.
Delete the solutions suo file. This has fixed weird debugging problems with breakpoints every time for me. Note, you will lose your solution settings, such as bookmarks, breakpoints, and such.
1) Does creating a new project work? If so, you have a corrupted settings somewhere. Moving your files over to your new project would be the easiest procedure to resolve your issue.
2) Does taking your solution to another PC work? If so, then you have an issue with your environment.
Try these checks in order:
1) Select your Configuration Manager, check if your CPU is "Any" or your "x86" or "x64" depending on your hardware.
2) Try remove all the other configuration other than Debug. Add a new Configuration based on your Debug and the CPU as Any
3) Drastic move.. close your visual studio and run the following
devenv /ResetSettings
4) Even more drastic move...
devenv /Setup
Good luck
There is a hotfix for Visual Studio SP1 regarding debugging issues here. It did fix issues I had with catching breakpoints in multithreaded source code. It also fixes other potential causes for breakpoints to be missed, so it is definitely worth a try.
Also, have a look at this SO question.
Regards.
I run into this occasionally and each time the solution is a bit different. This time I was using a different user profile to develop than I normally do in Visual Studio 2008 and found that I couldn't debug (breakpoints cannot be hit) shortly thereafter - on a solution with 2 vb.net projects. I ended up doing 2 things but I think the latter did the trick for me.
In the main projects properties, go to the Advanced Compile
Options button on the Compile tab and ensure the "Generate debug
info:" is set to Full.
Right-click on the main project and
select "Set as a startup project"
Working on an ASP.NET Project (not Web Site) and trying to Start without Debugging from Visual Studio.
First this:
alt text http://uploadimages.epiforge.com/Crash.png
Then this:
alt text http://uploadimages.epiforge.com/Burn.png
Once completely reinstalled Microsoft Visual Studio 2008 and it was fixed... for a while.
Looking for any information I can find, including:
What in the Hell is going on?
What way is there to fix it other than completely reinstalling VS2008?
How can it just be fixed permanently?
Try this - shouldn't take more than a minute or two.
Create a brand-spanking-new, empty Web Application Project. Enter something like "hello world" on the default.aspx page. Run it.
If your problem disappears, you've got something (3rd party DLL, etc) referenced in your project causing the issue.
Else, your looking at an OS, IDE or other environmental issue. I've had some odd VS issues in the past on Win7 that were solved by available updates. I still have to run VS as an administrator to use the "attach to process" for debugging.
update
So, the new project works, which tells us that the problem is somewhere in your old project. This is where the fun part starts, which is what I like to call "binary search debugging." It's crude, a pain in the ass, and if your app is pretty complex, sorting out dependencies can be a pain in the ass.
Create a new project and add all of your source to it.
Build, run. Did it work?
No? Remove half of the source.
Build. run. Did it work?
If so, the problem is in the half that you removed.
Else, it's in the half that remains.
Now, I know this is an incredibly naive approach to debugging, and its very brute-force, and some app configurations can make this damn near impossible, but at least its straightforward.
Any other service listening to the port number you're using? Try changing the port number or use IIS instead of running it on cassini.
I have a solution with 2 projects in Visual Studio 2008 SP1, .NET Framework 3.5 SP1.
a ASP Web site.
a Class Library (dll) project.
I have a reference from the Web Site to the Class Library, as the Class Library is my data layer. But anyway, the thing happens only with this basic setup, a solution with these 2 types of projects and a reference from the Web Site to the Class Library.
Now, each time I modify something in the Class Library and I build it, Visual Studio creates a file called app_offline.htm and then deletes it (it sends it to the Recycle Bin).
This is really annoying because at the end of the day I end up with a full Recycle Bin and me, being the perfectionist I am, I want to keep it clean. I'm not the only one with this problem: here and here.
I know now the cause of the problem, but still not how to fix it. If you didn't hear about app_offline.htm before, here's ScottGu's article on app_offline.:
Does anyone know a solution to the problem? Some setting in VS to delete the file forever after the Build process? (I really don't want to set my Recycle Bin to do that, as I do delete things unintentionally from time to time and I'd like to be able to recover those.)
This file does not go into the Recycle Bin for me. Perhaps you have some draconian utilities installed, which do this? Many anti-virus tools and general system utility suites used to do this back in 2000 but I do not have experience with later versions.
Update: You can use Process monitor to find out which process moves this file to the recycle bin.
[Disclaimer: I'm adding an answer firstly because I hope it will get the question seen by more people (I admit it) and secondly because I have no characters limit on an answer, as oposed to a comment.]
I followed Sander's suggestion and used Process Monitor to track which process moves this file to the Recycle Bin.
It was indeed devenv.exe.
There are several events where it makes operations like: QueryDirectory, QueryOpen, CreateFile and CloseFile. And devenv.exe is the only process that has anything to do with app_offline.htm
Still... How could I make Visual Studio stop filing up my Recycle Bin? (way to go, Dan, putting a question in the 'answer' (: )
I started seeing the same problem shortly after we suffered a VSTS server problem. The VSTS server went down for a day so I had to open the solution in offline mode. After the VSTS server came back online, I had to reopen the solution under source control, and the app_offline.htm files start occurring non-stop every time I recompile my web projects.
THIS IS REALLY ANNOYING!
I am not sure how to stop it yet, but I know how to reliably recreate the problem on my environment:
Windows XP Pro, VS2008, SourceGear (Source Control System).
Whenever I perform a checkout, the app_offline.htm file is instantly created and deleted in/from the root folder. The source control system is using SQL Enterprise, so I am not sure it is related to some references from posts people are making about SQL Express.
Again, still don't know how to stop it, but maybe this will help other figure out how/when the file is generated and deleted.
Use Web Application projects, not the Web Site templates, those are for 'dummies'. :)
I had this problem because I published directly to Azure Web Service from the dev machine.
The answer here with another possible workaround here.
This is all I could find on the subject. Unfortunately it's also speculation.
http://petermcg.wordpress.com/2008/05/12/silverlight-app-offline/
During our build process we run aspnet_compiler.exe against our websites to make sure that all the late-bound stuff in ASP.NET/MVC actually builds (I know nothing about ASP.NET but am assured this is necessary to prevent finding the failures at runtime).
Our sites are fairly large in size, with a few hundred pages/views/controls/etc. however the time taken seems excessive in the 10-15 minute range (for reference, this is longer than it takes the entire solution with approx 40 projects to compile, and we're only pre-compiling two website projects).
I doubt that hardware is the issue as I'm running on the latest Quad core Intel chip, with 4GB RAM and a WD Velociraptor 10,000rpm hard disk. And part of what's odd is that the EXE doesn't seem to be using much CPU (1-5%) and doesn't seem to be doing an awful lot of I/O either.
So... is this a known issue? Why is it so slow? And is there any way to speed it up?
Note: To clarify a couple of things people have answered about, I am not talking about the compilation of code within Visual Studio. We're using web application projects already, and the speed of compilation of those is not the issue. The problem is the pre-compilation of the site after these projects have already been compiled (see this MSDN page for more details) as part of the dev build script. We are performing in-place pre-compilation, not copying the files to a target directory.
Switching to Roslyn compiler most likely will significantly improve precompile time. Here is a good article about it: https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/.
In addition to this, make sure that batch compilation is enabled by setting batch attribute to true on the compilation element.
Simply, the aspnet_compiler uses what is effectively a "global compiler lock" whenever it starts pre-compiling any individual aspx page; it is basically only allowed to compile each page sequentially.
There are reasons for this (although I personally disagree with them) - primarily, in order to detect and prevent circular references causing an infinite loop of sorts, as well as ensuring that all dependencies are properly built before the requiring page is compiled, they avoid a lot of "nasty CS issues".
I once started writing a massively-forked version of aspnet_compiler.exe last time I worked at a web company, but got tied up with "real work" and never finished it. Biggest problem is the ASPX pages: the MVC/Razor stuff you can parallelize the HELL out of, but the ASPX parse/compile engine is about 20 levels deep of internal and private classes/methods.
Compiler should generate second code-behind file for every .aspx page, check
During compilation, aspnet_compiler.exe will copy ALL of the web site files to the output directory, including css, js and images.
You'll get better compilation times using Web application project instead of Web site model.
I don't have any specific hot tips for this compiler, but when I have this sort of problem, I run ProcMon to see what the process is doing on the machine, and I run Wireshark to check that it isn't spending ages timing-out some network access to a long-forgotten machine which is referenced in some registry key or environment variable.
Just my 2 cents.
One of the things slowing down ASP.NET views precompilation significantly is the -fixednames command line option for aspnet_compiler.exe. Do not use it especially if you're on Razor/MVC.
When publishing the wep app from Visual Studio make sure you select "Do not merge", and do not select "create separate assembly" cause this is what causes the global lock and slows things down.
More info here https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx